From w3c-dist-auth-request@w3.org Fri Feb 1 13:45:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07487 for ; Fri, 1 Feb 2002 13:45:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA18205; Fri, 1 Feb 2002 13:36:17 -0500 (EST) Resent-Date: Fri, 1 Feb 2002 13:36:17 -0500 (EST) Resent-Message-Id: <200202011836.NAA18205@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 NAA18180 for ; Fri, 1 Feb 2002 13:36:09 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA06863 for ; Fri, 1 Feb 2002 13:36:09 -0500 Received: (qmail 11350 invoked by uid 0); 1 Feb 2002 18:36:05 -0000 Received: from pd9e515c6.dip.t-dialin.net (HELO lisa) (217.229.21.198) by mail.gmx.net (mp001-rz3) with SMTP; 1 Feb 2002 18:36:05 -0000 From: "Julian Reschke" To: Date: Fri, 1 Feb 2002 19:36:04 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: Datatypes for WebDAV properties (internet draft draft-reschke-webdav-property-datatypes-01) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5872 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 have updated our proposal for marshalling property datatype information (see [1] and [2]). The main change was the addition of a chapter that shows marshalling of array types as implemented in the SAP Portals Enterprise Portal System's WebDAV protocol handlers. Feedback appreciated. Regards, Julian [1] [2] From w3c-dist-auth-request@w3.org Mon Feb 4 14:07:36 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03318 for ; Mon, 4 Feb 2002 14:07:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA16109; Mon, 4 Feb 2002 14:05:19 -0500 (EST) Resent-Date: Mon, 4 Feb 2002 14:05:19 -0500 (EST) Resent-Message-Id: <200202041905.OAA16109@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 OAA16083 for ; Mon, 4 Feb 2002 14:05:09 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA32450 for ; Mon, 4 Feb 2002 14:05:09 -0500 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g14J53706645 for ; Mon, 4 Feb 2002 11:05:03 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 4 Feb 2002 11:05:03 -0800 Received: from luthj1 (luthj1.apple.com [17.201.21.213]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g14J52011588 for ; Mon, 4 Feb 2002 11:05:02 -0800 (PST) Date: Mon, 4 Feb 2002 11:05:02 -0800 Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Jim Luther To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit Message-Id: <17613F8B-19A2-11D6-BBB6-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.480) Subject: Whatever happened with Partial PUTs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5873 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, Last week I posted something to the HTTP list (copied below) and I've received no response. So this morning I searched the w3c archives and found that my issue had been discussed before on this list (see and look for "Partial Put"). However, I didn't find that the issue of partial or ranged PUTs has ever been resolved. As Yaron Goland said at the time , "As anyone running on a 28.8 modem or less will tell you, this isn't an optimization, this features determines if the user can function." I wouldn't limit that to 28.8 modems -- with large enough files, this can even affect users with fast connections. I know that mod_dav allows Content-Range headers with PUTs. However, it only allows a file's existing content to be changed and for new content to be appended to the end of the existing content. We also need to be able to change the length of a resource without changing the content. So, what happened with this issue? Jim Luther Apple Computer, Inc. > From: Jim Luther > Date: Thu Jan 31, 2002 06:13:20 PM US/Pacific > To: http-wg@cuckoo.hpl.hp.com > Subject: Ranged PUT and changing an entity's length > > Hi, > > Mac OS X has a file system which uses HTTP and the WebDAV extensions. > Today, when an file entity on a DAV server is opened with write access, > our file system GETs the entire entity from the server and then works > with the local copy. When that entity is closed or synced, the local > copy is PUT back to the server. > > I'd like to change our code so that individual write requests to the > server entity are write-through to the server, but to do that, I need > to be able to do a ranged PUT with the range possibly starting and > ending beyond the entity's current instance-length (the current length > of the entity on the server). In addition, to be able to handle seek > and truncate requests, I need to be able to change the instance-length > without changing any data to both to make the entity either larger or > smaller. > > RFC 2616 doesn't really say how a Content-Range header might be used to > specify a ranged PUT request (it only discusses how a server would use > it to reply to a ranged GET), and nowhere that I can find does the RFC > say how the length of an entity can be changed (although I was thinking > that maybe the byte-content-range-spec in a Content-Range header could > look something like "bytes */100" to set the length of an entity to 100 > without changing any data). > > So, my two questions: > > 1 - Are ranged PUTs possible and if so, what should the headers look > like? > > 2 - Can the length of an entity be changed and if so, what should the > headers look like? > > Thanks, > > Jim Luther > Apple Computer From w3c-dist-auth-request@w3.org Mon Feb 4 15:53:10 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05678 for ; Mon, 4 Feb 2002 15:53:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26724; Mon, 4 Feb 2002 15:52:10 -0500 (EST) Resent-Date: Mon, 4 Feb 2002 15:52:10 -0500 (EST) Resent-Message-Id: <200202042052.PAA26724@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 PAA26685 for ; Mon, 4 Feb 2002 15:51:51 -0500 (EST) 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 PAA16699 for ; Mon, 4 Feb 2002 15:51:51 -0500 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 PAA172870; Mon, 4 Feb 2002 15:48:08 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g14Kp5V104918; Mon, 4 Feb 2002 15:51:09 -0500 To: "Lisa Dusseault" Cc: "Julian Reschke" , "Stefan Eissing" , w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 4 Feb 2002 15:32:37 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/04/2002 03:51:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Is KEEPALIVE worth keeping? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5874 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: As per the note below.... again... if anyone has an interest in keeping KEEPALIVE alive, please speak up. I'll mark it for deletion next weekend if noone speaks up. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Lisa Dusseault" To: "Stefan Eissing" , Jason Crawford/Watson/IBM@IBMUS, "Julian Reschke" 01/31/2002 01:05 cc: PM Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE There is a much deeper issue with keepalive, and that is that no client at the interop claimed to use the feature. Therefore interoperability has not been, and cannot easily be, demonstrated. Are there now clients out there that can demonstrate that keepalive works? Or is it one of those ideas that just isn't useful enough to clients for them to implement? If its not useful enough for clients to implement, then it should be removed from WebDAV so the protocol can go to the next phase of standardization. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Thursday, January 31, 2002 7:50 AM > To: Jason Crawford; Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > [...] > > Julian alluded to the possibility of keepalive going away. FWIW... I > > don't see anything like that listed on the issues list. > > The issue is not explicitly on the list, however it is related > to COPY_LIVE_PROPS. > The issues I have with keepAlive are > a) how does the client know which property is live in the first place? > b) deltaV copy semantics forbid using keepAlive on version properties > c) If the destination is on another server, WebDAV has no means to > fulfill keepAlive. It is not possible to know if the remote server > knows the requested live props. > d) Is there any server/client using it? (I have not seen any) > > I would propose to > 1) remove keepalive, maybe allow omit > 2) change default copy behaviour to _not_ copy live properties > > //Stefan > > > J. > > > > ------------------------------ Julian wrote... -------------------- > > Hi. > > > > Currently, RFC2518 says in 12.12.1 [1]: > > > > > > > > So individual properties are identified by "href" (which doesn't > > make sense > > in the general case). > > > > So (assuming that propertybehaviour/keepalive isn't dropped > anyway), this > > will need to be changed to: > > > > > > > > where DAV:prop contains property elements. > > > > Julian > > > > > > [1] > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > > From w3c-dist-auth-request@w3.org Mon Feb 4 16:46:28 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06564 for ; Mon, 4 Feb 2002 16:46:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05136; Mon, 4 Feb 2002 16:45:30 -0500 (EST) Resent-Date: Mon, 4 Feb 2002 16:45:30 -0500 (EST) Resent-Message-Id: <200202042145.QAA05136@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 QAA05116 for ; Mon, 4 Feb 2002 16:45:17 -0500 (EST) 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 QAA26928 for ; Mon, 4 Feb 2002 16:45:16 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 18602252; Mon, 04 Feb 2002 13:42:02 -0800 From: "Lisa Dusseault" To: "Jim Luther" , Date: Mon, 4 Feb 2002 13:43:05 -0800 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 In-Reply-To: <17613F8B-19A2-11D6-BBB6-0003934B6A22@apple.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Whatever happened with Partial PUTs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5875 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 Here's a rough proposal on your topic: http://www.sharemation.com/~milele/public/rsync-specification.htm RSync is a rather powerful tool for the purpose because the client doesn't have to maintain a past history of copies of the file in order to provide the server with diffs (the reverse is also true). There was also some interest on this kind of thing on the dav-dev list recently. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Monday, February 04, 2002 11:05 AM > To: w3c-dist-auth@w3c.org > Subject: Whatever happened with Partial PUTs > > > Hi, > > Last week I posted something to the HTTP list (copied below) and I've > received no response. So this morning I searched the w3c archives and > found that my issue had been discussed before on this list (see > auth/1997JanMar/thread.html> and look for "Partial Put"). However, I > didn't find that the issue of partial or ranged PUTs has ever been > resolved. > > As Yaron Goland said at the time > auth/1997JanMar/0258.html>, "As anyone running on a 28.8 modem or less > will tell you, this isn't an optimization, this features determines if > the user can function." I wouldn't limit that to 28.8 modems -- with > large enough files, this can even affect users with fast connections. > > I know that mod_dav allows Content-Range headers with PUTs. However, it > only allows a file's existing content to be changed and for new content > to be appended to the end of the existing content. We also need to be > able to change the length of a resource without changing the content. > > So, what happened with this issue? > > Jim Luther > Apple Computer, Inc. > > > From: Jim Luther > > Date: Thu Jan 31, 2002 06:13:20 PM US/Pacific > > To: http-wg@cuckoo.hpl.hp.com > > Subject: Ranged PUT and changing an entity's length > > > > Hi, > > > > Mac OS X has a file system which uses HTTP and the WebDAV extensions. > > Today, when an file entity on a DAV server is opened with write access, > > our file system GETs the entire entity from the server and then works > > with the local copy. When that entity is closed or synced, the local > > copy is PUT back to the server. > > > > I'd like to change our code so that individual write requests to the > > server entity are write-through to the server, but to do that, I need > > to be able to do a ranged PUT with the range possibly starting and > > ending beyond the entity's current instance-length (the current length > > of the entity on the server). In addition, to be able to handle seek > > and truncate requests, I need to be able to change the instance-length > > without changing any data to both to make the entity either larger or > > smaller. > > > > RFC 2616 doesn't really say how a Content-Range header might be used to > > specify a ranged PUT request (it only discusses how a server would use > > it to reply to a ranged GET), and nowhere that I can find does the RFC > > say how the length of an entity can be changed (although I was thinking > > that maybe the byte-content-range-spec in a Content-Range header could > > look something like "bytes */100" to set the length of an entity to 100 > > without changing any data). > > > > So, my two questions: > > > > 1 - Are ranged PUTs possible and if so, what should the headers look > > like? > > > > 2 - Can the length of an entity be changed and if so, what should the > > headers look like? > > > > Thanks, > > > > Jim Luther > > Apple Computer > From w3c-dist-auth-request@w3.org Mon Feb 4 18:19:51 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08084 for ; Mon, 4 Feb 2002 18:19:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA12969; Mon, 4 Feb 2002 18:18:27 -0500 (EST) Resent-Date: Mon, 4 Feb 2002 18:18:27 -0500 (EST) Resent-Message-Id: <200202042318.SAA12969@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 SAA12946 for ; Mon, 4 Feb 2002 18:18:14 -0500 (EST) 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 SAA06468 for ; Mon, 4 Feb 2002 18:18:15 -0500 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 PAA20151 for ; Mon, 4 Feb 2002 15:18:17 -0800 (PST) From: "Jim Whitehead" To: Date: Mon, 4 Feb 2002 15:16:56 -0800 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Is KEEPALIVE worth keeping? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5876 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 We originally envisioned that there would be servers with multiple sets of live properties active in different parts of its namespace, in which case it was unclear how to handle the semantics of a COPY from one live property space to another. Keepalive was designed to make these copies more predictable from the client side. But, these kinds of servers aren't prevalent, and it's not clear that clients really want these semantics anyway. The lack of adoption speaks volumes. I'm in favor of dumping it -- a later extension could add it back in, if desired. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Monday, February 04, 2002 12:33 PM > To: Lisa Dusseault > Cc: Julian Reschke; Stefan Eissing; w3c-dist-auth@w3.org > Subject: Is KEEPALIVE worth keeping? > > > > As per the note below.... again... if anyone has an interest in keeping > KEEPALIVE alive, please speak up. I'll mark it for deletion next weekend > if noone speaks up. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > > > > "Lisa Dusseault" > > To: "Stefan > Eissing" , Jason > > Crawford/Watson/IBM@IBMUS, "Julian Reschke" > 01/31/2002 01:05 cc: > > PM Subject: RE: > Issue: IS_HREF_A_CHILD_OF_KEEPALIVE > > > > > > > > > > There is a much deeper issue with keepalive, and that is that no client at > the interop claimed to use the feature. Therefore interoperability has > not > been, and cannot easily be, demonstrated. > > Are there now clients out there that can demonstrate that keepalive works? > Or is it one of those ideas that just isn't useful enough to clients for > them to implement? > > If its not useful enough for clients to implement, then it should be > removed > from WebDAV so the protocol can go to the next phase of standardization. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > > Sent: Thursday, January 31, 2002 7:50 AM > > To: Jason Crawford; Julian Reschke > > Cc: w3c-dist-auth@w3.org > > Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > > [...] > > > Julian alluded to the possibility of keepalive going away. > FWIW... I > > > don't see anything like that listed on the issues list. > > > > The issue is not explicitly on the list, however it is related > > to COPY_LIVE_PROPS. > > The issues I have with keepAlive are > > a) how does the client know which property is live in the first place? > > b) deltaV copy semantics forbid using keepAlive on version properties > > c) If the destination is on another server, WebDAV has no means to > > fulfill keepAlive. It is not possible to know if the remote server > > knows the requested live props. > > d) Is there any server/client using it? (I have not seen any) > > > > I would propose to > > 1) remove keepalive, maybe allow omit > > 2) change default copy behaviour to _not_ copy live properties > > > > //Stefan > > > > > J. > > > > > > ------------------------------ Julian wrote... -------------------- > > > Hi. > > > > > > Currently, RFC2518 says in 12.12.1 [1]: > > > > > > > > > > > > So individual properties are identified by "href" (which doesn't > > > make sense > > > in the general case). > > > > > > So (assuming that propertybehaviour/keepalive isn't dropped > > anyway), this > > > will need to be changed to: > > > > > > > > > > > > where DAV:prop contains property elements. > > > > > > Julian > > > > > > > > > [1] > > > > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Feb 6 05:46:38 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16213 for ; Wed, 6 Feb 2002 05:46:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA22722; Wed, 6 Feb 2002 05:45:05 -0500 (EST) Resent-Date: Wed, 6 Feb 2002 05:45:05 -0500 (EST) Resent-Message-Id: <200202061045.FAA22722@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 FAA22692 for ; Wed, 6 Feb 2002 05:44:49 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA08412 for ; Wed, 6 Feb 2002 05:44:48 -0500 Received: (qmail 21620 invoked by uid 0); 6 Feb 2002 10:44:17 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 6 Feb 2002 10:44:17 -0000 From: "Julian Reschke" To: "Jason Crawford" , Date: Wed, 6 Feb 2002 11:44:17 +0100 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Issue: DAV_WITH_COLON_IS_NOT_A_URI Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5877 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, I think we should add: "if a decision is made not to change the namespace name for DAV, the new spec should explain that a) defining a new URI scheme and b) using the scheme name as namespace name were bad design decisions and shouldn't be repeated". (I mention this because I just found yet another example of this abuse, and it seems to be inspired by WebDAV) Julian From w3c-dist-auth-request@w3.org Wed Feb 6 11:13:53 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24774 for ; Wed, 6 Feb 2002 11:13:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA12260; Wed, 6 Feb 2002 11:12:34 -0500 (EST) Resent-Date: Wed, 6 Feb 2002 11:12:34 -0500 (EST) Resent-Message-Id: <200202061612.LAA12260@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 LAA12231 for ; Wed, 6 Feb 2002 11:12:26 -0500 (EST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA19799 for ; Wed, 6 Feb 2002 11:12:26 -0500 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g16GCPQ25232 for ; Wed, 6 Feb 2002 08:12:25 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 6 Feb 2002 08:12:25 -0800 Received: from luthj1 (luthj1.apple.com [17.201.21.213]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g16GCOA13022 for ; Wed, 6 Feb 2002 08:12:24 -0800 (PST) Date: Wed, 6 Feb 2002 08:12:24 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) From: Jim Luther To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <17613F8B-19A2-11D6-BBB6-0003934B6A22@apple.com> Message-Id: <4E55AA52-1B1C-11D6-AA84-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.480) Subject: Re: Whatever happened with Partial PUTs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5878 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 found the answer by searching through the archives some more (it was under PUT-RANGE). gives the reason why PUT-RANGE wasn't left in the HTTP 1.1 specification and is where PUT-RANGE was officially removed from Rev-02 of the HTTP 1.1 spec. I guess we'll look at using something Mac OS X client/Apple iDisk server specific until there's a standard way to do ranged PUTs. - Jim Luther On Monday, February 4, 2002, at 11:05 AM, Jim Luther wrote: > Hi, > > Last week I posted something to the HTTP list (copied below) and I've > received no response. So this morning I searched the w3c archives and > found that my issue had been discussed before on this list (see > auth/1997JanMar/thread.html> and look for "Partial Put"). However, I > didn't find that the issue of partial or ranged PUTs has ever been > resolved. > > As Yaron Goland said at the time > auth/1997JanMar/0258.html>, "As anyone running on a 28.8 modem or less > will tell you, this isn't an optimization, this features determines if > the user can function." I wouldn't limit that to 28.8 modems -- with > large enough files, this can even affect users with fast connections. > > I know that mod_dav allows Content-Range headers with PUTs. However, it > only allows a file's existing content to be changed and for new content > to be appended to the end of the existing content. We also need to be > able to change the length of a resource without changing the content. > > So, what happened with this issue? > > Jim Luther > Apple Computer, Inc. > >> From: Jim Luther >> Date: Thu Jan 31, 2002 06:13:20 PM US/Pacific >> To: http-wg@cuckoo.hpl.hp.com >> Subject: Ranged PUT and changing an entity's length >> >> Hi, >> >> Mac OS X has a file system which uses HTTP and the WebDAV extensions. >> Today, when an file entity on a DAV server is opened with write >> access, our file system GETs the entire entity from the server and >> then works with the local copy. When that entity is closed or synced, >> the local copy is PUT back to the server. >> >> I'd like to change our code so that individual write requests to the >> server entity are write-through to the server, but to do that, I need >> to be able to do a ranged PUT with the range possibly starting and >> ending beyond the entity's current instance-length (the current length >> of the entity on the server). In addition, to be able to handle seek >> and truncate requests, I need to be able to change the instance-length >> without changing any data to both to make the entity either larger or >> smaller. >> >> RFC 2616 doesn't really say how a Content-Range header might be used >> to specify a ranged PUT request (it only discusses how a server would >> use it to reply to a ranged GET), and nowhere that I can find does the >> RFC say how the length of an entity can be changed (although I was >> thinking that maybe the byte-content-range-spec in a Content-Range >> header could look something like "bytes */100" to set the length of an >> entity to 100 without changing any data). >> >> So, my two questions: >> >> 1 - Are ranged PUTs possible and if so, what should the headers look >> like? >> >> 2 - Can the length of an entity be changed and if so, what should the >> headers look like? >> >> Thanks, >> >> Jim Luther >> Apple Computer > From w3c-dist-auth-request@w3.org Thu Feb 7 04:36:48 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23486 for ; Thu, 7 Feb 2002 04:36:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA13560; Thu, 7 Feb 2002 04:35:13 -0500 (EST) Resent-Date: Thu, 7 Feb 2002 04:35:13 -0500 (EST) Resent-Message-Id: <200202070935.EAA13560@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 EAA13524 for ; Thu, 7 Feb 2002 04:34:54 -0500 (EST) Received: from fullname.com (IDENT:root@paxil.bluescreen.org [216.160.123.12]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA10639 for ; Thu, 7 Feb 2002 04:34:53 -0500 Received: from wolverine (zoloft.bluescreen.org [216.160.123.11] (may be forged)) (authenticated) by fullname.com (8.11.0/8.11.0) with ESMTP id g179Yqs27584; Thu, 7 Feb 2002 01:34:52 -0800 Old-X-Envelope-To: w3c-dist-auth@w3.org Message-ID: <005901c1afba$2cb91730$5f00a8c0@wolverine> From: "Josh" To: "Julian Reschke" , "Jason Crawford" , References: Date: Thu, 7 Feb 2002 01:31:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Re: Issue: DAV_WITH_COLON_IS_NOT_A_URI Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5879 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 is an interesting point. It makes me wonder what a better solution would have been ? Im not suggesting invalidating the current scheme, but Im curious, what would be the right way to do it if we had the choice today ? ----- Original Message ----- From: "Julian Reschke" To: "Jason Crawford" ; Sent: Wednesday, February 06, 2002 2:44 AM Subject: Issue: DAV_WITH_COLON_IS_NOT_A_URI > Jason, > > I think we should add: "if a decision is made not to change the namespace > name for DAV, the new spec should explain that a) defining a new URI scheme > and b) using the scheme name as namespace name were bad design decisions and > shouldn't be repeated". > > (I mention this because I just found yet another example of this abuse, and > it seems to be inspired by WebDAV) > > Julian > > > From w3c-dist-auth-request@w3.org Thu Feb 7 05:30:44 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24281 for ; Thu, 7 Feb 2002 05:30:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19096; Thu, 7 Feb 2002 05:12:56 -0500 (EST) Resent-Date: Thu, 7 Feb 2002 05:12:56 -0500 (EST) Resent-Message-Id: <200202071012.FAA19096@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 FAA19058 for ; Thu, 7 Feb 2002 05:12:35 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA15910 for ; Thu, 7 Feb 2002 05:12:34 -0500 Received: (qmail 19649 invoked by uid 0); 7 Feb 2002 10:12:03 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 7 Feb 2002 10:12:03 -0000 From: "Julian Reschke" To: "Josh" , "Julian Reschke" , "Jason Crawford" , Date: Thu, 7 Feb 2002 11:12:02 +0100 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: <005901c1afba$2cb91730$5f00a8c0@wolverine> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Issue: DAV_WITH_COLON_IS_NOT_A_URI Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5880 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 don't invent a new URI scheme (it's not needed, and no semantics have been defined by RFC2518 for it). "http://webdav.org/" would have been perfect instead :-). > -----Original Message----- > From: Josh [mailto:josh@bluescreen.org] > Sent: Thursday, February 07, 2002 10:31 AM > To: Julian Reschke; Jason Crawford; w3c-dist-auth@w3.org > Subject: Re: Issue: DAV_WITH_COLON_IS_NOT_A_URI > > > This is an interesting point. It makes me wonder what a better > solution would have been ? Im not suggesting invalidating the > current scheme, but Im curious, what would be the right > way to do it if we had the choice today ? > > ----- Original Message ----- > From: "Julian Reschke" > To: "Jason Crawford" ; > Sent: Wednesday, February 06, 2002 2:44 AM > Subject: Issue: DAV_WITH_COLON_IS_NOT_A_URI > > > > Jason, > > > > I think we should add: "if a decision is made not to change the > namespace > > name for DAV, the new spec should explain that a) defining a new URI > scheme > > and b) using the scheme name as namespace name were bad design decisions > and > > shouldn't be repeated". > > > > (I mention this because I just found yet another example of this abuse, > and > > it seems to be inspired by WebDAV) > > > > Julian > > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 7 08:01:40 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25802 for ; Thu, 7 Feb 2002 08:01:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA07329; Thu, 7 Feb 2002 08:00:23 -0500 (EST) Resent-Date: Thu, 7 Feb 2002 08:00:23 -0500 (EST) Resent-Message-Id: <200202071300.IAA07329@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 IAA07283 for ; Thu, 7 Feb 2002 08:00:05 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-087176.rational.com [130.213.87.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA03676 for ; Thu, 7 Feb 2002 08:00:05 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Thu, 07 Feb 2002 07:59:02 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <1L4ZGTMK>; Thu, 7 Feb 2002 07:59:33 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105B81E0F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 7 Feb 2002 07:59:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Issue: DAV_WITH_COLON_IS_NOT_A_URI Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5881 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. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, February 06, 2002 5:44 AM To: Jason Crawford; w3c-dist-auth@w3.org Subject: Issue: DAV_WITH_COLON_IS_NOT_A_URI Jason, I think we should add: "if a decision is made not to change the namespace name for DAV, the new spec should explain that a) defining a new URI scheme and b) using the scheme name as namespace name were bad design decisions and shouldn't be repeated". (I mention this because I just found yet another example of this abuse, and it seems to be inspired by WebDAV) Julian From w3c-dist-auth-request@w3.org Thu Feb 7 12:15:36 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02821 for ; Thu, 7 Feb 2002 12:15:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA06443; Thu, 7 Feb 2002 12:14:20 -0500 (EST) Resent-Date: Thu, 7 Feb 2002 12:14:20 -0500 (EST) Resent-Message-Id: <200202071714.MAA06443@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 MAA06384 for ; Thu, 7 Feb 2002 12:13:58 -0500 (EST) 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 MAA03597 for ; Thu, 7 Feb 2002 12:13:59 -0500 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 MAA349754; Thu, 7 Feb 2002 12:10:19 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g17HDQS18668; Thu, 7 Feb 2002 12:13:26 -0500 To: "Julian Reschke" , w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 7 Feb 2002 12:01:50 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/07/2002 12:13:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5882 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: Hey everyone... The following posting about four months ago was not answered. Do we have an answer? Is this a general problem for properties? Let's hear what you think... BTW... I'd like to mention, but not necessarily recommend an option. See (d) below. > > Hi, > > if for some reason a server doesn't have one of these timestamps for a > resource, what should it report on PROPFIND for these properties? > > a) Property not found (HTTP 404), > > b) Empty property (this seem to be backed by the wording in section 7.4 > [1], > but is reported as error by Adobe GoLive, > > c) Property silently suppressed (not reported at all) -- this > seems to work > with GoLive. d) Return a fixed but not correctly supported value. For example, always respond with 1/1/1990. > > In addition, how should the server behaviour upon a PROPFIND/propname on > this resource? > > Julian > ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Feb 7 12:57:01 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03716 for ; Thu, 7 Feb 2002 12:57:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA09746; Thu, 7 Feb 2002 12:55:54 -0500 (EST) Resent-Date: Thu, 7 Feb 2002 12:55:54 -0500 (EST) Resent-Message-Id: <200202071755.MAA09746@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 MAA09705 for ; Thu, 7 Feb 2002 12:55:30 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-087176.rational.com [130.213.87.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA11830 for ; Thu, 7 Feb 2002 12:55:29 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Thu, 07 Feb 2002 12:54:26 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <1L4ZHDH9>; Thu, 7 Feb 2002 12:54:57 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AF7E@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 7 Feb 2002 12:54:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5883 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: 2518 is at best ambiguous, and a worst, contradictory on this topic. I would vote for (a) property not found. (b) is a possible interpretation, but an empty value violates the DTD for this property. The comment about "mandatory properties" in section 7.4 is not very useful, because "mandatory properties" is never defined in 2518. (c) violates the requirement in 8.1 that missing property errors be reported (d) is just obviously wrong (:-). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Thursday, February 07, 2002 12:02 PM To: Julian Reschke; w3c-dist-auth@w3.org Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Hey everyone... The following posting about four months ago was not answered. Do we have an answer? Is this a general problem for properties? Let's hear what you think... BTW... I'd like to mention, but not necessarily recommend an option. See (d) below. > > Hi, > > if for some reason a server doesn't have one of these timestamps for a > resource, what should it report on PROPFIND for these properties? > > a) Property not found (HTTP 404), > > b) Empty property (this seem to be backed by the wording in section 7.4 > [1], > but is reported as error by Adobe GoLive, > > c) Property silently suppressed (not reported at all) -- this > seems to work > with GoLive. d) Return a fixed but not correctly supported value. For example, always respond with 1/1/1990. > > In addition, how should the server behaviour upon a PROPFIND/propname on > this resource? > > Julian > ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Feb 7 13:02:58 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03873 for ; Thu, 7 Feb 2002 13:02:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10621; Thu, 7 Feb 2002 13:01:37 -0500 (EST) Resent-Date: Thu, 7 Feb 2002 13:01:37 -0500 (EST) Resent-Message-Id: <200202071801.NAA10621@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 NAA10578 for ; Thu, 7 Feb 2002 13:01:23 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA12872 for ; Thu, 7 Feb 2002 13:01:19 -0500 Received: (qmail 21043 invoked by uid 0); 7 Feb 2002 18:00:48 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp013-rz3) with SMTP; 7 Feb 2002 18:00:48 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Thu, 7 Feb 2002 19:00:47 +0100 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AF7E@SUS-MA1IT01> Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5884 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 Clemm, Geoff > Sent: Thursday, February 07, 2002 6:55 PM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > 2518 is at best ambiguous, and a worst, contradictory on this topic. > > I would vote for (a) property not found. > > (b) is a possible interpretation, but an empty value > violates the DTD for this property. Why would that be a violation? From w3c-dist-auth-request@w3.org Thu Feb 7 15:35:29 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09059 for ; Thu, 7 Feb 2002 15:35:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA29498; Thu, 7 Feb 2002 15:33:38 -0500 (EST) Resent-Date: Thu, 7 Feb 2002 15:33:38 -0500 (EST) Resent-Message-Id: <200202072033.PAA29498@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 PAA29424 for ; Thu, 7 Feb 2002 15:33:19 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-087176.rational.com [130.213.87.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA10243 for ; Thu, 7 Feb 2002 15:33:18 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Thu, 07 Feb 2002 15:32:14 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <1L4ZHLT8>; Thu, 7 Feb 2002 15:32:46 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AF83@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 7 Feb 2002 15:32:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5885 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: Well, there always is that question about whether is a node with no children, or a node with a single empty string child. Since section 2.4 of the xml spec says: "All text that is not markup constitutes the character data of the document", and since I do not consider "nothing" to be "text", I go with the interpretation that says contains no character data, and therefore does not match a #PCDATA declaration. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, February 07, 2002 1:01 PM To: Clemm, Geoff; w3c-dist-auth@w3.org Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, February 07, 2002 6:55 PM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > 2518 is at best ambiguous, and a worst, contradictory on this topic. > > I would vote for (a) property not found. > > (b) is a possible interpretation, but an empty value > violates the DTD for this property. Why would that be a violation? From w3c-dist-auth-request@w3.org Fri Feb 8 03:41:00 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01235 for ; Fri, 8 Feb 2002 03:41:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA14333; Fri, 8 Feb 2002 03:39:24 -0500 (EST) Resent-Date: Fri, 8 Feb 2002 03:39:24 -0500 (EST) Resent-Message-Id: <200202080839.DAA14333@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 DAA14270 for ; Fri, 8 Feb 2002 03:38:58 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA26865 for ; Fri, 8 Feb 2002 03:38:57 -0500 Received: (qmail 23007 invoked by uid 0); 8 Feb 2002 08:38:26 -0000 Received: from pd9535d9f.dip.t-dialin.net (HELO lisa) (217.83.93.159) by mail.gmx.net (mp002-rz3) with SMTP; 8 Feb 2002 08:38:26 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 8 Feb 2002 09:38:24 +0100 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: <3906C56A7BD1F54593344C05BD1374B103F8AF83@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5886 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 Geoff, as far as I can tell, PCDATA is defined in: http://www.w3.org/TR/2000/REC-xml-20001006#NT-Mixed where it says: [Definition: An element type has mixed content when elements of that type may contain character data, optionally interspersed with child elements.] In this case, the types of the child elements may be constrained, but not their order or their number of occurrences: Note the "may". Besides, this would mean that with DTDs you can't have elements that are restricted to arbitrary text content, but may not be empty. This is clearly not the case. Finally: in doubt, try it with a validating parser. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, February 07, 2002 9:33 PM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > Well, there always is that question about whether > is a node with no children, or a node with a single empty > string child. Since section 2.4 of the xml spec says: > "All text that is not markup constitutes the character data of the > document", > and since I do not consider "nothing" to be "text", I go with the > interpretation that says contains no character data, > and therefore does not match a #PCDATA declaration. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, February 07, 2002 1:01 PM > To: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Thursday, February 07, 2002 6:55 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > 2518 is at best ambiguous, and a worst, contradictory on this topic. > > > > I would vote for (a) property not found. > > > > (b) is a possible interpretation, but an empty value > > violates the DTD for this property. > > Why would that be a violation? > From w3c-dist-auth-request@w3.org Fri Feb 8 08:42:52 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06204 for ; Fri, 8 Feb 2002 08:42:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA16280; Fri, 8 Feb 2002 08:34:47 -0500 (EST) Resent-Date: Fri, 8 Feb 2002 08:34:47 -0500 (EST) Resent-Message-Id: <200202081334.IAA16280@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 IAA16241 for ; Fri, 8 Feb 2002 08:34:29 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-087176.rational.com [130.213.87.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA31242 for ; Fri, 8 Feb 2002 08:34:29 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 08 Feb 2002 08:33:23 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <1L4Z2H2Q>; Fri, 8 Feb 2002 08:33:57 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105CE04DD@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 8 Feb 2002 08:33:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5887 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: Yes, I'd agree that this clearly supports Julian's position that an empty element of the form "" matches a #PCDATA DTD declaration. So I modify my rejection of choice (i.e. returning an empty element) to be: The definition of DAV:creationdate states: "If present, it contains a timestamp of the moment when the resource was created". An empty value does not meet this requirement (although one could debate the meaning of "present"). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, February 08, 2002 3:38 AM To: Clemm, Geoff; w3c-dist-auth@w3.org Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Geoff, as far as I can tell, PCDATA is defined in: http://www.w3.org/TR/2000/REC-xml-20001006#NT-Mixed where it says: [Definition: An element type has mixed content when elements of that type may contain character data, optionally interspersed with child elements.] In this case, the types of the child elements may be constrained, but not their order or their number of occurrences: Note the "may". Besides, this would mean that with DTDs you can't have elements that are restricted to arbitrary text content, but may not be empty. This is clearly not the case. Finally: in doubt, try it with a validating parser. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, February 07, 2002 9:33 PM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > Well, there always is that question about whether > is a node with no children, or a node with a single empty > string child. Since section 2.4 of the xml spec says: > "All text that is not markup constitutes the character data of the > document", > and since I do not consider "nothing" to be "text", I go with the > interpretation that says contains no character data, > and therefore does not match a #PCDATA declaration. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, February 07, 2002 1:01 PM > To: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Thursday, February 07, 2002 6:55 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > 2518 is at best ambiguous, and a worst, contradictory on this topic. > > > > I would vote for (a) property not found. > > > > (b) is a possible interpretation, but an empty value > > violates the DTD for this property. > > Why would that be a violation? > From w3c-dist-auth-request@w3.org Fri Feb 8 19:19:32 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28028 for ; Fri, 8 Feb 2002 19:19:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA02873; Fri, 8 Feb 2002 10:40:55 -0500 (EST) Resent-Date: Fri, 8 Feb 2002 10:40:55 -0500 (EST) Resent-Message-Id: <200202081540.KAA02873@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 KAA02633 for ; Fri, 8 Feb 2002 10:40:12 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA32442 for ; Fri, 8 Feb 2002 08:42:15 -0500 Received: (qmail 21042 invoked by uid 0); 8 Feb 2002 13:41:43 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 8 Feb 2002 13:41:43 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 8 Feb 2002 14:41:42 +0100 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: <3906C56A7BD1F54593344C05BD1374B105CE04DD@SUS-MA1IT01> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5889 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 OK, so what's your suggestion then? a) or c)? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, February 08, 2002 2:34 PM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > Yes, I'd agree that this clearly supports Julian's position > that an empty element of the form "" matches a #PCDATA > DTD declaration. > > So I modify my rejection of choice (i.e. returning an empty > element) to be: The definition of DAV:creationdate states: > "If present, it contains a timestamp of the moment when the > resource was created". An empty value does not meet this > requirement (although one could debate the meaning of "present"). > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, February 08, 2002 3:38 AM > To: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > Geoff, > > as far as I can tell, PCDATA is defined in: > > http://www.w3.org/TR/2000/REC-xml-20001006#NT-Mixed > > where it says: > > [Definition: An element type has mixed content when elements of that type > may contain character data, optionally interspersed with child > elements.] In > this case, the types of the child elements may be constrained, > but not their > order or their number of occurrences: > > Note the "may". > > Besides, this would mean that with DTDs you can't have elements that are > restricted to arbitrary text content, but may not be empty. This > is clearly > not the case. > > Finally: in doubt, try it with a validating parser. > > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Thursday, February 07, 2002 9:33 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > Well, there always is that question about whether > > is a node with no children, or a node with a single empty > > string child. Since section 2.4 of the xml spec says: > > "All text that is not markup constitutes the character data of the > > document", > > and since I do not consider "nothing" to be "text", I go with the > > interpretation that says contains no character data, > > and therefore does not match a #PCDATA declaration. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Thursday, February 07, 2002 1:01 PM > > To: Clemm, Geoff; w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > > Sent: Thursday, February 07, 2002 6:55 PM > > > To: w3c-dist-auth@w3.org > > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > > > > 2518 is at best ambiguous, and a worst, contradictory on this topic. > > > > > > I would vote for (a) property not found. > > > > > > (b) is a possible interpretation, but an empty value > > > violates the DTD for this property. > > > > Why would that be a violation? > > > From w3c-dist-auth-request@w3.org Fri Feb 8 19:20:29 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28056 for ; Fri, 8 Feb 2002 19:20:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA24167; Fri, 8 Feb 2002 09:35:55 -0500 (EST) Resent-Date: Fri, 8 Feb 2002 09:35:55 -0500 (EST) Resent-Message-Id: <200202081435.JAA24167@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 JAA24095 for ; Fri, 8 Feb 2002 09:35:29 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-087176.rational.com [130.213.87.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA07926 for ; Fri, 8 Feb 2002 09:35:28 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5; Fri, 08 Feb 2002 09:34:23 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <1L4Z2JX9>; Fri, 8 Feb 2002 09:34:57 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105CE0559@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 8 Feb 2002 09:34:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5888 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: My rationale for rejecting (c) was: "(c) violates the requirement in 8.1 that missing property errors be reported" So that leaves (a) as my choice for the most consistent interpretation of 2518. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, February 08, 2002 8:42 AM To: Clemm, Geoff; w3c-dist-auth@w3.org Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate OK, so what's your suggestion then? a) or c)? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, February 08, 2002 2:34 PM > To: w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > Yes, I'd agree that this clearly supports Julian's position > that an empty element of the form "" matches a #PCDATA > DTD declaration. > > So I modify my rejection of choice (i.e. returning an empty > element) to be: The definition of DAV:creationdate states: > "If present, it contains a timestamp of the moment when the > resource was created". An empty value does not meet this > requirement (although one could debate the meaning of "present"). > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, February 08, 2002 3:38 AM > To: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > Geoff, > > as far as I can tell, PCDATA is defined in: > > http://www.w3.org/TR/2000/REC-xml-20001006#NT-Mixed > > where it says: > > [Definition: An element type has mixed content when elements of that type > may contain character data, optionally interspersed with child > elements.] In > this case, the types of the child elements may be constrained, > but not their > order or their number of occurrences: > > Note the "may". > > Besides, this would mean that with DTDs you can't have elements that are > restricted to arbitrary text content, but may not be empty. This > is clearly > not the case. > > Finally: in doubt, try it with a validating parser. > > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Thursday, February 07, 2002 9:33 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > Well, there always is that question about whether > > is a node with no children, or a node with a single empty > > string child. Since section 2.4 of the xml spec says: > > "All text that is not markup constitutes the character data of the > > document", > > and since I do not consider "nothing" to be "text", I go with the > > interpretation that says contains no character data, > > and therefore does not match a #PCDATA declaration. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Thursday, February 07, 2002 1:01 PM > > To: Clemm, Geoff; w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > > Sent: Thursday, February 07, 2002 6:55 PM > > > To: w3c-dist-auth@w3.org > > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > > > > 2518 is at best ambiguous, and a worst, contradictory on this topic. > > > > > > I would vote for (a) property not found. > > > > > > (b) is a possible interpretation, but an empty value > > > violates the DTD for this property. > > > > Why would that be a violation? > > > From w3c-dist-auth-request@w3.org Fri Feb 8 20:12:43 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28691 for ; Fri, 8 Feb 2002 20:12:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA23316; Fri, 8 Feb 2002 20:07:15 -0500 (EST) Resent-Date: Fri, 8 Feb 2002 20:07:15 -0500 (EST) Resent-Message-Id: <200202090107.UAA23316@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 UAA23279 for ; Fri, 8 Feb 2002 20:06:58 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA11381 for ; Fri, 8 Feb 2002 20:06:57 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id RAA02479; Fri, 8 Feb 2002 17:07:23 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 8 Feb 2002 17:07:23 -0800 From: Greg Stein To: Jason Crawford Cc: w3c-dist-auth@w3.org Message-ID: <20020208170723.L1205@lyra.org> Mail-Followup-To: Jason Crawford , w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ccjason@us.ibm.com on Mon, Feb 04, 2002 at 03:32:37PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: Is KEEPALIVE worth keeping? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5890 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: mod_dav totally ignores the body of a MOVE or COPY request. So I'm all in favor of removing the whole darned thing :-). Short of that, tossing the keepalive stuff is at least a forward-step. Cheers, -g On Mon, Feb 04, 2002 at 03:32:37PM -0500, Jason Crawford wrote: > > As per the note below.... again... if anyone has an interest in keeping > KEEPALIVE alive, please speak up. I'll mark it for deletion next weekend > if noone speaks up. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > > > "Lisa Dusseault" > To: "Stefan Eissing" , Jason > Crawford/Watson/IBM@IBMUS, "Julian Reschke" > 01/31/2002 01:05 cc: > PM Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE > > > > > > > There is a much deeper issue with keepalive, and that is that no client at > the interop claimed to use the feature. Therefore interoperability has > not > been, and cannot easily be, demonstrated. > > Are there now clients out there that can demonstrate that keepalive works? > Or is it one of those ideas that just isn't useful enough to clients for > them to implement? > > If its not useful enough for clients to implement, then it should be > removed > from WebDAV so the protocol can go to the next phase of standardization. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > > Sent: Thursday, January 31, 2002 7:50 AM > > To: Jason Crawford; Julian Reschke > > Cc: w3c-dist-auth@w3.org > > Subject: RE: Issue: IS_HREF_A_CHILD_OF_KEEPALIVE > > > > > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > > [...] > > > Julian alluded to the possibility of keepalive going away. FWIW... I > > > don't see anything like that listed on the issues list. > > > > The issue is not explicitly on the list, however it is related > > to COPY_LIVE_PROPS. > > The issues I have with keepAlive are > > a) how does the client know which property is live in the first place? > > b) deltaV copy semantics forbid using keepAlive on version properties > > c) If the destination is on another server, WebDAV has no means to > > fulfill keepAlive. It is not possible to know if the remote server > > knows the requested live props. > > d) Is there any server/client using it? (I have not seen any) > > > > I would propose to > > 1) remove keepalive, maybe allow omit > > 2) change default copy behaviour to _not_ copy live properties > > > > //Stefan > > > > > J. > > > > > > ------------------------------ Julian wrote... -------------------- > > > Hi. > > > > > > Currently, RFC2518 says in 12.12.1 [1]: > > > > > > > > > > > > So individual properties are identified by "href" (which doesn't > > > make sense > > > in the general case). > > > > > > So (assuming that propertybehaviour/keepalive isn't dropped > > anyway), this > > > will need to be changed to: > > > > > > > > > > > > where DAV:prop contains property elements. > > > > > > Julian > > > > > > > > > [1] > > > > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > > > > > > > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Feb 8 20:27:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28871 for ; Fri, 8 Feb 2002 20:27:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA26734; Fri, 8 Feb 2002 20:22:32 -0500 (EST) Resent-Date: Fri, 8 Feb 2002 20:22:32 -0500 (EST) Resent-Message-Id: <200202090122.UAA26734@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 UAA26671 for ; Fri, 8 Feb 2002 20:22:14 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA12770 for ; Fri, 8 Feb 2002 20:22:14 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id RAA02499 for w3c-dist-auth@w3.org; Fri, 8 Feb 2002 17:22:48 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 8 Feb 2002 17:22:48 -0800 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20020208172247.M1205@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org References: <3906C56A7BD1F54593344C05BD1374B105CE0559@SUS-MA1IT01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105CE0559@SUS-MA1IT01>; from gclemm@rational.com on Fri, Feb 08, 2002 at 09:34:56AM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5891 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: If mod_dav's backend repository does not support the property, then it operates according to (a) already (return a 404). I think that makes the most sense (obviously :-), and would continue to vote for that option. Cheers, -g On Fri, Feb 08, 2002 at 09:34:56AM -0500, Clemm, Geoff wrote: > My rationale for rejecting (c) was: > "(c) violates the requirement in 8.1 that missing > property errors be reported" > > So that leaves (a) as my choice for the most consistent > interpretation of 2518. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, February 08, 2002 8:42 AM > To: Clemm, Geoff; w3c-dist-auth@w3.org > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > OK, > > so what's your suggestion then? a) or c)? > > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Friday, February 08, 2002 2:34 PM > > To: w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > Yes, I'd agree that this clearly supports Julian's position > > that an empty element of the form "" matches a #PCDATA > > DTD declaration. > > > > So I modify my rejection of choice (i.e. returning an empty > > element) to be: The definition of DAV:creationdate states: > > "If present, it contains a timestamp of the moment when the > > resource was created". An empty value does not meet this > > requirement (although one could debate the meaning of "present"). > > > > Cheers, > > Geoff > > > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Friday, February 08, 2002 3:38 AM > > To: Clemm, Geoff; w3c-dist-auth@w3.org > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > Geoff, > > > > as far as I can tell, PCDATA is defined in: > > > > http://www.w3.org/TR/2000/REC-xml-20001006#NT-Mixed > > > > where it says: > > > > [Definition: An element type has mixed content when elements of that type > > may contain character data, optionally interspersed with child > > elements.] In > > this case, the types of the child elements may be constrained, > > but not their > > order or their number of occurrences: > > > > Note the "may". > > > > Besides, this would mean that with DTDs you can't have elements that are > > restricted to arbitrary text content, but may not be empty. This > > is clearly > > not the case. > > > > Finally: in doubt, try it with a validating parser. > > > > > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > > Sent: Thursday, February 07, 2002 9:33 PM > > > To: w3c-dist-auth@w3.org > > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > > > > Well, there always is that question about whether > > > is a node with no children, or a node with a single empty > > > string child. Since section 2.4 of the xml spec says: > > > "All text that is not markup constitutes the character data of the > > > document", > > > and since I do not consider "nothing" to be "text", I go with the > > > interpretation that says contains no character data, > > > and therefore does not match a #PCDATA declaration. > > > > > > Cheers, > > > Geoff > > > > > > -----Original Message----- > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > Sent: Thursday, February 07, 2002 1:01 PM > > > To: Clemm, Geoff; w3c-dist-auth@w3.org > > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > > > Sent: Thursday, February 07, 2002 6:55 PM > > > > To: w3c-dist-auth@w3.org > > > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate > > > > > > > > > > > > 2518 is at best ambiguous, and a worst, contradictory on this topic. > > > > > > > > I would vote for (a) property not found. > > > > > > > > (b) is a possible interpretation, but an empty value > > > > violates the DTD for this property. > > > > > > Why would that be a violation? > > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Feb 11 13:23:32 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13259 for ; Mon, 11 Feb 2002 13:23:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA14366; Mon, 11 Feb 2002 13:17:26 -0500 (EST) Resent-Date: Mon, 11 Feb 2002 13:17:26 -0500 (EST) Resent-Message-Id: <200202111817.NAA14366@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 NAA14337 for ; Mon, 11 Feb 2002 13:17:09 -0500 (EST) 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 NAA16048 for ; Mon, 11 Feb 2002 13:17:08 -0500 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 NAA157998; Mon, 11 Feb 2002 13:13:27 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1BIGYu228220; Mon, 11 Feb 2002 13:16:34 -0500 To: Greg Stein Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 11 Feb 2002 13:03:56 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/11/2002 01:16:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Is KEEPALIVE worth keeping? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5892 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: Okay, I'll mark dav:keepalive as slated for removal from the spec due to the fact that it isn't implemented and apparently not valued. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Feb 13 13:14:26 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15953 for ; Wed, 13 Feb 2002 13:14:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13908; Wed, 13 Feb 2002 13:09:35 -0500 (EST) Resent-Date: Wed, 13 Feb 2002 13:09:35 -0500 (EST) Resent-Message-Id: <200202131809.NAA13908@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 NAA13847 for ; Wed, 13 Feb 2002 13:09:13 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24214 for ; Wed, 13 Feb 2002 13:09:13 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1DI7I610700 for ; Wed, 13 Feb 2002 10:07:18 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1DI8x729615 for ; Wed, 13 Feb 2002 10:08:59 -0800 (PST) Received: from c-62-190.corp.adobe.com ([153.32.62.190]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GRHH2900.S5G; Wed, 13 Feb 2002 10:08:34 -0800 Date: Wed, 13 Feb 2002 09:13:16 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org To: "Jason Crawford" From: Daniel Brotsky In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Subject: Re: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5894 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 On Monday, January 14, 2002, at 12:19 PM, Jason Crawford wrote: > > >> In addition to Geoff's answer: >> If you are an administrator trying to unlock a resource obtained by >> someone else, you have to be able to figure out which resource to >> unlock. You can't unlock an internal member of a collection that's >> locked by a depth-inifinity lock without knowing which collection was >> actually locked. > > CAN'T? > > >> Then you can decide whether unlocking that is the >> right thing to do. > > I think this is what Geoff was saying. He's saying it is probably > irresponsible to unlock a set of resources without knowing what > resources > actually will become unlocked. > > But apparently before this sentence you are saying something different > than Geoff. Please explain. I think I was just being mistaken :^). I was thinking that somehow you could just unlock that single element, rather than that the unlock would apply to the whole collection. That would be cute if you could do it :^). Please ignore... dan From w3c-dist-auth-request@w3.org Wed Feb 13 14:08:45 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15954 for ; Wed, 13 Feb 2002 13:14:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13888; Wed, 13 Feb 2002 13:09:26 -0500 (EST) Resent-Date: Wed, 13 Feb 2002 13:09:26 -0500 (EST) Resent-Message-Id: <200202131809.NAA13888@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 NAA13836 for ; Wed, 13 Feb 2002 13:09:11 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24211 for ; Wed, 13 Feb 2002 13:09:11 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1DI7G610682 for ; Wed, 13 Feb 2002 10:07:16 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1DI8v729594 for ; Wed, 13 Feb 2002 10:08:57 -0800 (PST) Received: from c-62-190.corp.adobe.com ([153.32.62.190]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GRHH2700.DBS; Wed, 13 Feb 2002 10:08:31 -0800 Date: Wed, 13 Feb 2002 09:09:58 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: w3c-dist-auth@w3.org To: "Clemm, Geoff" From: Daniel Brotsky In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AF7E@SUS-MA1IT01> Message-Id: <8204FF06-20A4-11D6-A27F-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Subject: Re: RFC2518 ambiguity on creationdate/lastmodifieddate Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5893 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've seen the whole thread on this topic; this just seems to be the most appropriate message to respond to...) On Thursday, February 7, 2002, at 09:54 AM, Clemm, Geoff wrote: > 2518 is at best ambiguous, and a worst, contradictory on this topic. Amen. > > I would vote for (a) property not found. So do I. > > (b) is a possible interpretation, but an empty value > violates the DTD for this property. > The comment about "mandatory properties" in section 7.4 is not > very useful, because "mandatory properties" is never defined in 2518. Actually I believe this language in section 7.4 is causing problems all over the place, and should become an issue in its own right (unless it's already in the lock-null resource issues elsewhere). As far as I can tell, it's the only place where the notion of "having no value" is suggested as a possibly different from and preferable to "not existing". The problem is this language ...Additionally the lock-null resource MUST have defined on it all mandatory DAV properties. Most of these properties, such as all the get* properties, will have no value as a lock-null resource does not support the GET method. First of all, as Geoff points out, there is no definition of "mandatory" properties anywhere. Second, this offhand "MUST have defined on it all mandatory DAV properties" is really bad language for a spec: the lock-null resource is either a resource (in which case the spec says elsewhere what MUST be true about it) or it's not (in which case this section should say explicitly how it MUST behave). Finally, the sentence starting "Most of these properties..." contradicts the example in 8.1.2, where a resource that doesn't support GET explicitly doesn't have the get* properties. I very much think the phrase "will have no value" was simply a think-o, and was meant to mean "will not be present on the resource". I really think we need to exorcise this language from the spec, and if we do there's no reason that I can see not to have (a) be the proper response when a specific property that's not present is asked for by name. This includes creationdate, which says in its description: The creationdate property should be defined on all DAV compliant resources. If present, it contains a timestamp of the moment when the resource was created (i.e., the moment it had non- null state). dan P.S. Yes I know that my own company's products are not consistent in their notions of what responses are appropriate for "mandatory" properties. But I don't think this paticular one is an issue where backwards-compatibility concerns should block fixing this ambiguity/self-contraduction in the spec: it may just be that older clients (some of which are Adobe's) will complain (hopefully not break) until they get upgraded. -d. P.P.S. I know there was discussion about the "empty vs. missing" property issue earlier, at least on dav-dev, but I don't have access to the archives right now. Do we have an issue about this already? -d. From w3c-dist-auth-request@w3.org Thu Feb 14 20:01:46 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13983 for ; Thu, 14 Feb 2002 20:01:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27129; Thu, 14 Feb 2002 19:58:13 -0500 (EST) Resent-Date: Thu, 14 Feb 2002 19:58:13 -0500 (EST) Resent-Message-Id: <200202150058.TAA27129@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 TAA27107 for ; Thu, 14 Feb 2002 19:57:57 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA26851 for ; Thu, 14 Feb 2002 19:57:57 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1F0wus14291 for ; Thu, 14 Feb 2002 16:58:56 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1F0vi711426 for ; Thu, 14 Feb 2002 16:57:44 -0800 (PST) Received: from dhcp16.local.brotsky.com ([130.248.184.88]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GRJUNJ00.JYQ for ; Thu, 14 Feb 2002 16:57:19 -0800 Date: Thu, 14 Feb 2002 16:57:51 -0800 Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Daniel Brotsky To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit Message-Id: <09AE2686-21AF-11D6-88EB-0003931036B4@adobe.com> X-Mailer: Apple Mail (2.480) Subject: re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5895 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 On Aug 17 last year, in , Jason closed this issue using the Geoff's language about "act as if a PUT of length 0 happened." Since I was on vacation at that time, I missed this conclusion, but don't worry: I agree with it!! (phew :^) But it raises a question (other than the 201 status response Lisa already raised) and I believe it closes another issue I rasied: The question: what's the mime-type of the newly-created resource? Now I know that many servers use file extensions to determine mime-type, so the name of the resource could be used to provide a mime-type. But for other servers that expect clients to supply a Content-type header on PUT (or at least pay attention to them), what should happen? My proposal: do not mandate behavior around this; leave the spec silent. That way the spec is silent about mime-type of LOCK created resources exactly as it's silent about the mime type of PUT resources. The issue: LOCK_URL_WITH_NO_PARENT_COLLECTION In I asked that LOCK return 409 with no body when parent collections don't exist. There was no discussion (which at the time I took to be assent but the issue was never closed), but with this change in LOCK semantics I believe the issue is forced: LOCK must return 409 (with no body) exactly as PUT does when there are missing parent collections. So I think this issue should be closed as accepted, unless anyone has a problem with the language I specified in my original message. dan From w3c-dist-auth-request@w3.org Fri Feb 15 03:42:48 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00138 for ; Fri, 15 Feb 2002 03:42:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA19595; Fri, 15 Feb 2002 03:41:10 -0500 (EST) Resent-Date: Fri, 15 Feb 2002 03:41:10 -0500 (EST) Resent-Message-Id: <200202150841.DAA19595@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 DAA19574 for ; Fri, 15 Feb 2002 03:40:55 -0500 (EST) 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 DAA21588 for ; Fri, 15 Feb 2002 03:40:54 -0500 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 15 Feb 2002 09:40:06 +0100 Date: Fri, 15 Feb 2002 09:40:06 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) From: Stefan Eissing To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <09AE2686-21AF-11D6-88EB-0003931036B4@adobe.com> Message-Id: <9CA625C8-21EF-11D6-8DD2-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.480) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5896 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 Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky: > On Aug 17 last year, in auth/2001JulSep/0141.html>, Jason closed this issue using the > Geoff's language about "act as if a PUT of length 0 happened." > > Since I was on vacation at that time, I missed this conclusion, > but don't worry: I agree with it!! (phew :^) But it raises a > question (other than the 201 status response Lisa already raised) > and I believe it closes another issue I rasied: > > The question: what's the mime-type of the newly-created resource? > > Now I know that many servers use file extensions to determine > mime-type, so the name of the resource could be used to provide a > mime-type. But for other servers that expect clients to supply a > Content-type header on PUT (or at least pay attention to them), > what should happen? > > My proposal: do not mandate behavior around this; leave the spec > silent. That way the spec is silent about mime-type of LOCK > created resources exactly as it's silent about the mime type of > PUT resources. Yesterday we had internally the discussion about the mime-type of a resource with length 0. I think we did not come to a good conclusion and the whole mime-type handling is a mess anyway. The only thing we could agree upon is that a client supplied mime-type on PUT should be persistet (if possible) and override any name extension guesswork. > The issue: LOCK_URL_WITH_NO_PARENT_COLLECTION > > In auth/2001JanMar/0134.html> I asked that LOCK return 409 with no > body when parent collections don't exist. There was no discussion > (which at the time I took to be assent but the issue was never > closed), but with this change in LOCK semantics I believe the > issue is forced: LOCK must return 409 (with no body) exactly as > PUT does when there are missing parent collections. So I think > this issue should be closed as accepted, unless anyone has a > problem with the language I specified in my original message. Returning 409 sounds reasonable. From w3c-dist-auth-request@w3.org Fri Feb 15 15:35:00 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18764 for ; Fri, 15 Feb 2002 15:35:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA03589; Fri, 15 Feb 2002 15:33:24 -0500 (EST) Resent-Date: Fri, 15 Feb 2002 15:33:24 -0500 (EST) Resent-Message-Id: <200202152033.PAA03589@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 PAA03559 for ; Fri, 15 Feb 2002 15:33:06 -0500 (EST) 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 PAA01601 for ; Fri, 15 Feb 2002 15:33:06 -0500 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 PAA456598 for ; Fri, 15 Feb 2002 15:29:24 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1FKWX0189356 for ; Fri, 15 Feb 2002 15:32:33 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 15 Feb 2002 15:32:24 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/15/2002 03:32:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: LOCK_URL_WITH_NO_PARENT_COLLECTION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5897 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: > The issue: LOCK_URL_WITH_NO_PARENT_COLLECTION > > In auth/2001JanMar/0134.html> I asked that LOCK return 409 with no > body when parent collections don't exist. There was no discussion > (which at the time I took to be assent but the issue was never > closed), but with this change in LOCK semantics I believe the > issue is forced: LOCK must return 409 (with no body) exactly as > PUT does when there are missing parent collections. So I think > this issue should be closed as accepted, unless anyone has a > problem with the language I specified in my original message. I'll update the issues list to reflect this. Since I believe there is nothing in the spec to suggest otherwise, I'll also note that we should check that the text we add to remove the existance of LNR's should not be ambiguous on this topic. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Feb 15 16:21:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19933 for ; Fri, 15 Feb 2002 16:21:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA08257; Fri, 15 Feb 2002 16:20:19 -0500 (EST) Resent-Date: Fri, 15 Feb 2002 16:20:19 -0500 (EST) Resent-Message-Id: <200202152120.QAA08257@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 QAA08231 for ; Fri, 15 Feb 2002 16:20:13 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08268 for ; Fri, 15 Feb 2002 16:20:12 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1FLIGj11980 for ; Fri, 15 Feb 2002 13:18:16 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1FLK0708322 for ; Fri, 15 Feb 2002 13:20:00 -0800 (PST) Received: from dhcp16.local.brotsky.com ([130.248.184.88]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GRLF8N00.QYT; Fri, 15 Feb 2002 13:19:35 -0800 Date: Fri, 15 Feb 2002 13:20:06 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: w3c-dist-auth@w3c.org To: "Jason Crawford" From: Daniel Brotsky In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Subject: Re: LOCK_URL_WITH_NO_PARENT_COLLECTION Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5898 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 my original message there is a suggested update of the LOCK method section that reflects the two possible meanings of 409. I would suggest we integrate it into the spec. dan On Friday, February 15, 2002, at 12:32 PM, Jason Crawford wrote: >> The issue: LOCK_URL_WITH_NO_PARENT_COLLECTION >> >> In > auth/2001JanMar/0134.html> I asked that LOCK return 409 with no >> body when parent collections don't exist. There was no discussion >> (which at the time I took to be assent but the issue was never >> closed), but with this change in LOCK semantics I believe the >> issue is forced: LOCK must return 409 (with no body) exactly as >> PUT does when there are missing parent collections. So I think >> this issue should be closed as accepted, unless anyone has a >> problem with the language I specified in my original message. > > I'll update the issues list to reflect this. Since I believe there is > nothing in the spec to > suggest otherwise, I'll also note that we should check that the text we > add > to remove > the existance of LNR's should not be ambiguous on this topic. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Sat Feb 16 17:21:36 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17193 for ; Sat, 16 Feb 2002 17:21:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA11234; Sat, 16 Feb 2002 17:13:02 -0500 (EST) Resent-Date: Sat, 16 Feb 2002 17:13:02 -0500 (EST) Resent-Message-Id: <200202162213.RAA11234@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 RAA11028 for ; Sat, 16 Feb 2002 17:12:17 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA04350 for ; Sat, 16 Feb 2002 17:12:16 -0500 Received: from moose ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id g1GMCAb03746 for ; Sat, 16 Feb 2002 14:12:10 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: Date: Sat, 16 Feb 2002 14:13:26 -0800 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 V6.00.2600.0000 Importance: Normal Subject: Shared locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5899 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 Has independent interoperability been demonstrated with RFC2518 shared locks? If you believe it has been, what are the clients and servers with which it was demonstrated? thanks, Lisa From w3c-dist-auth-request@w3.org Sat Feb 16 22:23:54 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21248 for ; Sat, 16 Feb 2002 22:23:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA15288; Sat, 16 Feb 2002 22:19:00 -0500 (EST) Resent-Date: Sat, 16 Feb 2002 22:19:00 -0500 (EST) Resent-Message-Id: <200202170319.WAA15288@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 WAA15197 for ; Sat, 16 Feb 2002 22:18:18 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA30208 for ; Sat, 16 Feb 2002 22:18:18 -0500 Received: from moose ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id g1H3IDb25274; Sat, 16 Feb 2002 19:18:13 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Stefan Eissing" , Date: Sat, 16 Feb 2002 19:19:28 -0800 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <9CA625C8-21EF-11D6-8DD2-00039384827E@greenbytes.de> Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5900 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 Stefan Eissing wrote: > Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky: > > > The question: what's the mime-type of the newly-created resource? > > > > Now I know that many servers use file extensions to determine > > mime-type, so the name of the resource could be used to provide a > > mime-type. But for other servers that expect clients to supply a > > Content-type header on PUT (or at least pay attention to them), > > what should happen? > > > > My proposal: do not mandate behavior around this; leave the spec > > silent. That way the spec is silent about mime-type of LOCK > > created resources exactly as it's silent about the mime type of > > PUT resources. > > Yesterday we had internally the discussion about the mime-type of > a resource with length 0. I think we did not come to a good conclusion > and the whole mime-type handling is a mess anyway. > > The only thing we could agree upon is that a client supplied mime-type > on PUT should be persistet (if possible) and override any name extension > guesswork. Application/octet-stream is the generally accepted "don't know what else to use" MIME type, the default MIME type. At least if we specify it, behavior will definitely be consistent. What's the virtue of not specifying it? I do agree that when a content-type is included in a PUT overwriting the empty resource, that should become the new content-type. However isn't that always the case, whether the resource was previously empty or not? Lisa From w3c-dist-auth-request@w3.org Mon Feb 18 05:07:38 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29473 for ; Mon, 18 Feb 2002 05:07:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19120; Mon, 18 Feb 2002 05:05:02 -0500 (EST) Resent-Date: Mon, 18 Feb 2002 05:05:02 -0500 (EST) Resent-Message-Id: <200202181005.FAA19120@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 FAA19097 for ; Mon, 18 Feb 2002 05:04:36 -0500 (EST) 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 FAA12853 for ; Mon, 18 Feb 2002 05:04:35 -0500 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 18 Feb 2002 11:03:48 +0100 Date: Mon, 18 Feb 2002 11:03:51 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: To: "Lisa Dusseault" From: Stefan Eissing In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5901 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 Am Sonntag den, 17. Februar 2002, um 04:19, schrieb Lisa Dusseault: > > Stefan Eissing wrote: >> Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky: >> >>> The question: what's the mime-type of the newly-created resource? >>> >>> Now I know that many servers use file extensions to determine >>> mime-type, so the name of the resource could be used to provide a >>> mime-type. But for other servers that expect clients to supply a >>> Content-type header on PUT (or at least pay attention to them), >>> what should happen? >>> >>> My proposal: do not mandate behavior around this; leave the spec >>> silent. That way the spec is silent about mime-type of LOCK >>> created resources exactly as it's silent about the mime type of >>> PUT resources. >> >> Yesterday we had internally the discussion about the mime-type of >> a resource with length 0. I think we did not come to a good conclusion >> and the whole mime-type handling is a mess anyway. >> >> The only thing we could agree upon is that a client supplied mime-type >> on PUT should be persistet (if possible) and override any name >> extension >> guesswork. > > Application/octet-stream is the generally accepted "don't know > what else to > use" MIME type, the default MIME type. At least if we specify it, > behavior > will definitely be consistent. What's the virtue of not specifying it? Can we specify answers for all questions below? 1. When a client creates a resource with "application/octet-stream", should the server make a guess and replace octet-stream with another mime type? 2. When a client creates a resource without mime type, should the server make a guess or report application/octet-stream? 3. When a server reports application/octet-stream, should a client take a guess in order to open an application/show an icon? 4. When a server reports another mime type, is a client allowed to take a guess anyway and disregard the server supplied mime type? How does a client know that the mime type was not "guessed" by the server? > I do agree that when a content-type is included in a PUT > overwriting the > empty resource, that should become the new content-type. However > isn't that > always the case, whether the resource was previously empty or not? Yes. The question is more what content-type to report on an empty resource. > Lisa > From w3c-dist-auth-request@w3.org Mon Feb 18 07:11:52 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00939 for ; Mon, 18 Feb 2002 07:11:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA27667; Mon, 18 Feb 2002 07:08:39 -0500 (EST) Resent-Date: Mon, 18 Feb 2002 07:08:39 -0500 (EST) Resent-Message-Id: <200202181208.HAA27667@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 HAA27641 for ; Mon, 18 Feb 2002 07:08:26 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA31233 for ; Mon, 18 Feb 2002 07:08:25 -0500 Received: (qmail 16176 invoked by uid 0); 18 Feb 2002 12:08:15 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 18 Feb 2002 12:08:15 -0000 From: "Julian Reschke" To: "Stefan Eissing" , "Lisa Dusseault" Cc: Date: Mon, 18 Feb 2002 13:08:15 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5902 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 Stefan Eissing > Sent: Monday, February 18, 2002 11:04 AM > To: Lisa Dusseault > Cc: w3c-dist-auth@w3c.org > Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > Am Sonntag den, 17. Februar 2002, um 04:19, schrieb Lisa Dusseault: > > > > > Stefan Eissing wrote: > >> Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky: > >> > >>> The question: what's the mime-type of the newly-created resource? > >>> > >>> Now I know that many servers use file extensions to determine > >>> mime-type, so the name of the resource could be used to provide a > >>> mime-type. But for other servers that expect clients to supply a > >>> Content-type header on PUT (or at least pay attention to them), > >>> what should happen? > >>> > >>> My proposal: do not mandate behavior around this; leave the spec > >>> silent. That way the spec is silent about mime-type of LOCK > >>> created resources exactly as it's silent about the mime type of > >>> PUT resources. > >> > >> Yesterday we had internally the discussion about the mime-type of > >> a resource with length 0. I think we did not come to a good conclusion > >> and the whole mime-type handling is a mess anyway. > >> > >> The only thing we could agree upon is that a client supplied mime-type > >> on PUT should be persistet (if possible) and override any name > >> extension > >> guesswork. > > > > Application/octet-stream is the generally accepted "don't know > > what else to > > use" MIME type, the default MIME type. At least if we specify it, > > behavior > > will definitely be consistent. What's the virtue of not specifying it? > > Can we specify answers for all questions below? > > 1. When a client creates a resource with > "application/octet-stream", should > the server make a guess and replace octet-stream with another mime type? No. As per RFC2616, 7.2.1: If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octetstream". > 2. When a client creates a resource without mime type, should > the server make a guess or report application/octet-stream? It could, but I wouldn't recommend that. It may make sense to report a *specific* content type (such as application/x-foobar), but reporting "application/octet-stream" doesn't really help anybody. > 3. When a server reports application/octet-stream, should a client take > a guess in order to open an application/show an icon? No. See above. > 4. When a server reports another mime type, is a client allowed to take > a guess anyway and disregard the server supplied mime type? How does Good question. RFC2616 forbids that. > a client know that the mime type was not "guessed" by the server? It can't. So it makes sense to let the server only guess if it's reasonably sure that it's correct (and useful). > > I do agree that when a content-type is included in a PUT > > overwriting the > > empty resource, that should become the new content-type. However > > isn't that > > always the case, whether the resource was previously empty or not? > > Yes. The question is more what content-type to report on an empty > resource. Wether or not a specific content type is valid for an empty resource depends on the content type. I don't think that this needs to be treated different from non-empty resources. Julian From w3c-dist-auth-request@w3.org Mon Feb 18 09:32:52 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03815 for ; Mon, 18 Feb 2002 09:32:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA07581; Mon, 18 Feb 2002 09:29:58 -0500 (EST) Resent-Date: Mon, 18 Feb 2002 09:29:58 -0500 (EST) Resent-Message-Id: <200202181429.JAA07581@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 JAA07557 for ; Mon, 18 Feb 2002 09:29:48 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA20955 for ; Mon, 18 Feb 2002 09:29:48 -0500 Received: (qmail 14333 invoked by uid 0); 18 Feb 2002 14:29:17 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 18 Feb 2002 14:29:17 -0000 From: "Julian Reschke" To: Date: Mon, 18 Feb 2002 15:29:17 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5903 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, currently RFC2518 is silent on this issue. However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC." I think something similar needs to be added to the revision to RFC2518. Looking at current implementations I notice that the Microsoft Webfolder client (sigh!) does a PROPFIND on no less than then 10 proprietary properties placed into the DAV: namespace ([2]), of which it only seems to *use* one (DAV:ishidden). Without wiring special knowledge about these attributes into a server, it will usually have to consult the resource's dead properties (just to find out that these don't exist). Would it be permissible to assume that properties in the DAV: namespace *never* are dead properties, allowing to skip this step? Julian [1] [2] From w3c-dist-auth-request@w3.org Mon Feb 18 10:59:23 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05884 for ; Mon, 18 Feb 2002 10:59:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA14522; Mon, 18 Feb 2002 10:56:41 -0500 (EST) Resent-Date: Mon, 18 Feb 2002 10:56:41 -0500 (EST) Resent-Message-Id: <200202181556.KAA14522@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 KAA14457 for ; Mon, 18 Feb 2002 10:56:09 -0500 (EST) Received: from mail0.rawbw.com (mail0.rawbw.com [198.144.192.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA06344 for ; Mon, 18 Feb 2002 10:56:08 -0500 Received: from moose ([198.144.203.248]) by mail0.rawbw.com (8.11.3/8.11.3) with SMTP id g1IFu6b53146; Mon, 18 Feb 2002 07:56:07 -0800 (PST) (envelope-from lisa@xythos.com) From: "Lisa Dusseault" To: "Webdav WG" , "Julian Reschke" Date: Mon, 18 Feb 2002 07:57:16 -0800 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 V6.00.2600.0000 Importance: Normal 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/5904 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 > > 2. When a client creates a resource without mime type, should > > the server make a guess or report application/octet-stream? > > It could, but I wouldn't recommend that. It may make sense to report a > *specific* content type (such as application/x-foobar), but reporting > "application/octet-stream" doesn't really help anybody. > I'm not sure this is workable. You're right that defaulting to application/octet-stream doesn't help anybody, but it may hurt less. When a client creates a resource without a MIME type, then a client asks for the resource using GET, the server must put some value in the Content-Type header. Since "getcontenttype" is defined as the type that would be returned in the Content-Type header were the client to do a GET request, it must have the same value. This isn't a DAV problem only -- any Web server might have the same problem. Lisa From w3c-dist-auth-request@w3.org Mon Feb 18 15:36:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17168 for ; Mon, 18 Feb 2002 15:36:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13525; Mon, 18 Feb 2002 15:30:38 -0500 (EST) Resent-Date: Mon, 18 Feb 2002 15:30:38 -0500 (EST) Resent-Message-Id: <200202182030.PAA13525@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 PAA13484 for ; Mon, 18 Feb 2002 15:30:22 -0500 (EST) Received: from hq-exgw1.filenet.com (Filenet-gw.filenet.com [198.3.8.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12925 for ; Mon, 18 Feb 2002 15:30:21 -0500 Received: by cm-exgw1.filenet.com with Internet Mail Service (5.5.2653.19) id <14DMMSHV>; Mon, 18 Feb 2002 12:29:50 -0800 Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3c.org Date: Mon, 18 Feb 2002 12:25:28 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5905 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: "Would it be permissible to assume that properties in the DAV: namespace *never* are dead properties, allowing to skip this step?" I don't think so. Alan Babich -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, February 18, 2002 6:29 AM To: w3c-dist-auth@w3c.org Subject: Using DAV namespace for proprietary properties Hi, currently RFC2518 is silent on this issue. However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies can be extended by arbitrary XML elements, which can be ignored by the message recipient, an XML element in the DAV namespace MUST NOT be used in the request or response body of a versioning method unless that XML element is explicitly defined in an IETF RFC." I think something similar needs to be added to the revision to RFC2518. Looking at current implementations I notice that the Microsoft Webfolder client (sigh!) does a PROPFIND on no less than then 10 proprietary properties placed into the DAV: namespace ([2]), of which it only seems to *use* one (DAV:ishidden). Without wiring special knowledge about these attributes into a server, it will usually have to consult the resource's dead properties (just to find out that these don't exist). Would it be permissible to assume that properties in the DAV: namespace *never* are dead properties, allowing to skip this step? Julian [1] [2] From w3c-dist-auth-request@w3.org Mon Feb 18 19:12:41 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24259 for ; Mon, 18 Feb 2002 19:12:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA29322; Mon, 18 Feb 2002 19:10:57 -0500 (EST) Resent-Date: Mon, 18 Feb 2002 19:10:57 -0500 (EST) Resent-Message-Id: <200202190010.TAA29322@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 TAA29296 for ; Mon, 18 Feb 2002 19:10:41 -0500 (EST) 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 TAA04602 for ; Mon, 18 Feb 2002 19:10:42 -0500 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 TAA94160; Mon, 18 Feb 2002 19:06:59 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1J0A8C30688; Mon, 18 Feb 2002 19:10:08 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 18 Feb 2002 19:00:49 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/18/2002 07:10:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: IETF meeting: Refreshing locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5906 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: What does the following text from the SLC IETF meaning mean? > Refreshing Locks.... > > Consensus was to delete paragraph on lock refresh. > Eric - clients seem to be expecting locks to hang around, when they expire it causes problems. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Feb 19 02:45:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11902 for ; Tue, 19 Feb 2002 02:45:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA04478; Tue, 19 Feb 2002 02:44:22 -0500 (EST) Resent-Date: Tue, 19 Feb 2002 02:44:22 -0500 (EST) Resent-Message-Id: <200202190744.CAA04478@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 CAA04450 for ; Tue, 19 Feb 2002 02:44:07 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA19927 for ; Tue, 19 Feb 2002 02:44:06 -0500 Received: (qmail 18420 invoked by uid 0); 19 Feb 2002 07:43:35 -0000 Received: from p50824e66.dip.t-dialin.net (HELO lisa) (80.130.78.102) by mail.gmx.net (mp015-rz3) with SMTP; 19 Feb 2002 07:43:35 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Tue, 19 Feb 2002 08:43:34 +0100 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 V6.00.2600.0000 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/5907 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 Lisa Dusseault > Sent: Monday, February 18, 2002 4:57 PM > To: Webdav WG; Julian Reschke > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > > > 2. When a client creates a resource without mime type, should > > > the server make a guess or report application/octet-stream? > > > > It could, but I wouldn't recommend that. It may make sense to report a > > *specific* content type (such as application/x-foobar), but reporting > > "application/octet-stream" doesn't really help anybody. > > > > I'm not sure this is workable. You're right that defaulting to > application/octet-stream doesn't help anybody, but it may hurt > less. When a > client creates a resource without a MIME type, then a client asks for the > resource using GET, the server must put some value in the Content-Type > header. Since "getcontenttype" is defined as the type that would be No, it doesn't (as far as I can tell). RFC2616 says that the Content-Type SHOULD be present, but then goes on saying what a recipient is allowed to do when it's absent. So if you PUT without content type, cou can't *expect* that the magically will invent one. > returned in the Content-Type header were the client to do a GET > request, it > must have the same value. > > This isn't a DAV problem only -- any Web server might have the > same problem. Right, that's why RFC2616 is relevant. From w3c-dist-auth-request@w3.org Tue Feb 19 02:53:56 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11998 for ; Tue, 19 Feb 2002 02:53:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA04644; Tue, 19 Feb 2002 02:46:30 -0500 (EST) Resent-Date: Tue, 19 Feb 2002 02:46:30 -0500 (EST) Resent-Message-Id: <200202190746.CAA04644@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 CAA04620 for ; Tue, 19 Feb 2002 02:46:22 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA20117 for ; Tue, 19 Feb 2002 02:46:21 -0500 Received: (qmail 14306 invoked by uid 0); 19 Feb 2002 07:45:50 -0000 Received: from p50824e66.dip.t-dialin.net (HELO lisa) (80.130.78.102) by mail.gmx.net (mp016-rz3) with SMTP; 19 Feb 2002 07:45:50 -0000 From: "Julian Reschke" To: Date: Tue, 19 Feb 2002 08:45:49 +0100 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 V6.00.2600.0000 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/5908 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 Lisa Dusseault > Sent: Sunday, February 17, 2002 4:19 AM > To: Stefan Eissing; w3c-dist-auth@w3c.org > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC > > > >... > > Application/octet-stream is the generally accepted "don't know > what else to > use" MIME type, the default MIME type. At least if we specify > it, behavior > will definitely be consistent. What's the virtue of not specifying it? Because GET, PUT and content types are HTTP/1.1. So there's no point trying to redefine something in WebDAV when it's not required. From w3c-dist-auth-request@w3.org Tue Feb 19 02:54:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12021 for ; Tue, 19 Feb 2002 02:54:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA04689; Tue, 19 Feb 2002 02:47:11 -0500 (EST) Resent-Date: Tue, 19 Feb 2002 02:47:11 -0500 (EST) Resent-Message-Id: <200202190747.CAA04689@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 CAA04667 for ; Tue, 19 Feb 2002 02:47:05 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA20133 for ; Tue, 19 Feb 2002 02:47:04 -0500 Received: (qmail 30873 invoked by uid 0); 19 Feb 2002 07:47:00 -0000 Received: from p50824e66.dip.t-dialin.net (HELO lisa) (80.130.78.102) by mail.gmx.net (mp004-rz3) with SMTP; 19 Feb 2002 07:47:00 -0000 From: "Julian Reschke" To: "Babich, Alan" , Date: Tue, 19 Feb 2002 08:46:59 +0100 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 V6.00.2600.0000 In-reply-to: Importance: Normal Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5909 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 see. Could you please explain this position? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > Sent: Monday, February 18, 2002 9:25 PM > To: w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > "Would it be permissible to assume that properties in the DAV: namespace > *never* are dead properties, allowing to skip this step?" > > I don't think so. > > Alan Babich > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, February 18, 2002 6:29 AM > To: w3c-dist-auth@w3c.org > Subject: Using DAV namespace for proprietary properties > > > Hi, > > currently RFC2518 is silent on this issue. > > However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies > can be extended by arbitrary XML elements, which can be ignored by the > message recipient, an XML element in the DAV namespace MUST NOT be used in > the request or response body of a versioning method unless that > XML element > is explicitly defined in an IETF RFC." > > I think something similar needs to be added to the revision to RFC2518. > > Looking at current implementations I notice that the Microsoft Webfolder > client (sigh!) does a PROPFIND on no less than then 10 proprietary > properties placed into the DAV: namespace ([2]), of which it only seems to > *use* one (DAV:ishidden). Without wiring special knowledge about these > attributes into a server, it will usually have to consult the resource's > dead properties (just to find out that these don't exist). Would it be > permissible to assume that properties in the DAV: namespace > *never* are dead > properties, allowing to skip this step? > > Julian > > > [1] > [2] From w3c-dist-auth-request@w3.org Tue Feb 19 17:11:57 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06730 for ; Tue, 19 Feb 2002 17:11:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA26485; Tue, 19 Feb 2002 17:10:16 -0500 (EST) Resent-Date: Tue, 19 Feb 2002 17:10:16 -0500 (EST) Resent-Message-Id: <200202192210.RAA26485@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 RAA26464 for ; Tue, 19 Feb 2002 17:10:06 -0500 (EST) 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 RAA12079 for ; Tue, 19 Feb 2002 17:10:06 -0500 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 OAA17636 for ; Tue, 19 Feb 2002 14:10:10 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 19 Feb 2002 14:08:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: High Subject: WebDAV book authors Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5910 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: Susan Capparelle [mailto:suca@manning.com] Sent: Tuesday, February 19, 2002 11:40 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV book authors Hi, We're a publisher of high quality computer books currently seeking an author, or authors, to write on the topic of WebDAV. If you can recommend anyone with the necessary skills and experience to undertake a book like this, please feel free to contact us. We look forward to hearing back from you and thanks in advance. Sincerely, ======================================= Susan W. Capparelle Assistant Publisher Manning Publications Co. 209 Bruce Park Avenue, Greenwich, CT 06830 suca@manning.com tel. 203.629.2211 www.manning.com fax. 203.629.2084 ======================================= From w3c-dist-auth-request@w3.org Tue Feb 19 21:55:20 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11925 for ; Tue, 19 Feb 2002 21:55:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA16226; Tue, 19 Feb 2002 21:51:35 -0500 (EST) Resent-Date: Tue, 19 Feb 2002 21:51:35 -0500 (EST) Resent-Message-Id: <200202200251.VAA16226@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 VAA16202 for ; Tue, 19 Feb 2002 21:51:21 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA09798 for ; Tue, 19 Feb 2002 21:51:21 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA22156; Tue, 19 Feb 2002 18:52:41 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 19 Feb 2002 18:52:40 -0800 From: Greg Stein To: Julian Reschke Cc: Peter Gillis , dav-dev@lyra.org, w3c-dist-auth@w3.org, I20568n@mindshare.intraspect.com Message-ID: <20020219185240.W15965@lyra.org> Mail-Followup-To: Julian Reschke , Peter Gillis , dav-dev@lyra.org, w3c-dist-auth@w3.org, I20568n@mindshare.intraspect.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian.reschke@gmx.de on Wed, Feb 13, 2002 at 09:31:37PM +0100 X-URL: http://www.lyra.org/greg/ Subject: Re: [dav-dev] Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5912 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 Wed, Feb 13, 2002 at 09:31:37PM +0100, Julian Reschke wrote: >... > > From: dav-dev-admin@lyra.org [mailto:dav-dev-admin@lyra.org]On Behalf Of > > Peter Gillis > > Sent: Wednesday, February 13, 2002 8:46 PM >... > > I am having a problem with Microsoft Web Folders after the client installs > > Office XP on their machine and file names with accented characters are > > involved. Our server has been working in the past with earlier > > implementations of Web Folders without a problem, however, when the client > > machine is upgraded to Office XP, a document that was accessible > > previously > > is now not found. I have tracked the problem down to the fact that Web > > Folders is encoding the URI value a second time before sending > > the request, > > which then causes it not to be found on our server. For example: > > > > In the folder listing we send back the following property: > > > > /dav/webdav/%E8%E2temp%C9.xls > > Isn't this wrong in the first place? My understanding is that you should > send URL-encoded UTF-8. Nope. The filename is in an "original character set". That is then encoded into octets for the URL. That transformation is not specified anywhere. Ideally, it is "original -> UTF-8", but nobody says it must be. In fact, I would say it should match whatever encoding was used for the Request-URI (but that is not specified/defined in the request, so you're out of luck again). Once you have octets, then you perform the URL-escaping (using '%xx'). After that, you need to transform the URL into the character set of the response body. That is usually UTF-8, but it is possible to have the XML in a different character set (provided it is specified on the Content-Type response header). Finally, you must XML-escape the UTF-8 characters of the URL you're inserting (e.g. translate '&' to '&') so that you can embed the UTF-8 content into the XML response. A long time ago, I captured this as a start of a technical FAQ. See: http://www.webdav.org/other/techfaq.html Specifically, the second section. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Feb 20 03:54:46 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25280 for ; Wed, 20 Feb 2002 03:54:45 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA03607; Wed, 20 Feb 2002 03:53:08 -0500 (EST) Resent-Date: Wed, 20 Feb 2002 03:53:08 -0500 (EST) Resent-Message-Id: <200202200853.DAA03607@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 DAA03576 for ; Wed, 20 Feb 2002 03:52:39 -0500 (EST) 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 DAA14370 for ; Wed, 20 Feb 2002 03:52:38 -0500 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 20 Feb 2002 09:51:45 +0100 Date: Wed, 20 Feb 2002 09:51:46 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: Julian Reschke , Peter Gillis , dav-dev@lyra.org, w3c-dist-auth@w3.org, I20568n@mindshare.intraspect.com To: Greg Stein From: Stefan Eissing In-Reply-To: <20020219185240.W15965@lyra.org> Message-Id: <125AB42B-25DF-11D6-8032-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: [dav-dev] Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5913 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 Am Mittwoch den, 20. Februar 2002, um 03:52, schrieb Greg Stein: > On Wed, Feb 13, 2002 at 09:31:37PM +0100, Julian Reschke wrote: >> ... >>> From: dav-dev-admin@lyra.org [mailto:dav-dev-admin@lyra.org]On >>> Behalf Of >>> Peter Gillis >>> Sent: Wednesday, February 13, 2002 8:46 PM >> ... >>> I am having a problem with Microsoft Web Folders after the client >>> installs >>> Office XP on their machine and file names with accented >>> characters are >>> involved. Our server has been working in the past with earlier >>> implementations of Web Folders without a problem, however, when >>> the client >>> machine is upgraded to Office XP, a document that was accessible >>> previously >>> is now not found. I have tracked the problem down to the fact >>> that Web >>> Folders is encoding the URI value a second time before sending >>> the request, >>> which then causes it not to be found on our server. For example: >>> >>> In the folder listing we send back the following property: >>> >>> /dav/webdav/%E8%E2temp%C9.xls >> >> Isn't this wrong in the first place? My understanding is that you >> should >> send URL-encoded UTF-8. > > Nope. > > The filename is in an "original character set". That is then > encoded into > octets for the URL. That transformation is not specified anywhere. > Ideally, > it is "original -> UTF-8", but nobody says it must be. In fact, I > would say > it should match whatever encoding was used for the Request-URI > (but that is > not specified/defined in the request, so you're out of luck again). I dare to disagree. The URI must be UTF-8 encoded. Otherwise you lose interoperability. Assume you take 8859-1 in your response document and apply a stylesheet which outputs UTF-8. XSTL does not know that it should change the text child nodes of elements. You already mentioned request-URIs where the encoding is not known. //Stefan From w3c-dist-auth-request@w3.org Wed Feb 20 15:41:58 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19386 for ; Wed, 20 Feb 2002 15:41:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06936; Wed, 20 Feb 2002 15:40:22 -0500 (EST) Resent-Date: Wed, 20 Feb 2002 15:40:22 -0500 (EST) Resent-Message-Id: <200202202040.PAA06936@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 PAA06895 for ; Wed, 20 Feb 2002 15:40:00 -0500 (EST) 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 PAA28125 for ; Wed, 20 Feb 2002 15:40:00 -0500 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 PAA251100 for ; Wed, 20 Feb 2002 15:36:17 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1KKdQ035838 for ; Wed, 20 Feb 2002 15:39:26 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 20 Feb 2002 15:29:33 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/20/2002 03:39:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5916 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: Do we feel there is a change in the 2518 spec needed in regard to the following posting by Julian... > currently RFC2518 is silent on this issue. > > However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies > can be extended by arbitrary XML elements, which can be ignored by the > message recipient, an XML element in the DAV namespace MUST NOT be used in > the request or response body of a versioning method unless that XML element > is explicitly defined in an IETF RFC." > > I think something similar needs to be added to the revision to RFC2518. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Feb 20 16:35:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21118 for ; Wed, 20 Feb 2002 16:35:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA11338; Wed, 20 Feb 2002 16:29:22 -0500 (EST) Resent-Date: Wed, 20 Feb 2002 16:29:22 -0500 (EST) Resent-Message-Id: <200202202129.QAA11338@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 OAA01042 for ; Wed, 20 Feb 2002 14:51:31 -0500 (EST) 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 OAA13454 for ; Wed, 20 Feb 2002 14:01:14 -0500 Received: from [216.36.111.249] (HELO moose) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.3) with SMTP id 20087588 for w3c-dist-auth@w3c.org; Wed, 20 Feb 2002 10:56:34 -0800 From: "Lisa Dusseault" To: "Webdav WG" Date: Wed, 20 Feb 2002 11:01:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0140_01C1B9FE.04CB2B20" 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 V6.00.2600.0000 Importance: Normal Subject: New draft: RFC2518bis Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5917 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_0140_01C1B9FE.04CB2B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I've submitted this new draft this week because there's a deadline for new drafts this Friday. However it appears I can submit changes sometime before a later deadline. This draft doesn't deal with all the open issues. Some open issues are listed in "RFC2518 Changes.doc", which is available temporarily at http://www.sharemation.com/~milele/public/dav until I get these docs up on www.webdav.org. You can also find there "RFC2518 Revised.doc" which is a convenient way to see the change bars done by Word. I can provide any of these documents in some other formats if needed. We'll be discussing this in Minneapolis, so come one, come all! Lisa ------=_NextPart_000_0140_01C1B9FE.04CB2B20 Content-Type: text/plain; name="draft-ietf-webdav-rfc2518bis-00.txt" Content-Disposition: attachment; filename="draft-ietf-webdav-rfc2518bis-00.txt" Content-Transfer-Encoding: quoted-printable Y. Goland, Microsoft=20 Internet Draft E. Whitehead, UCSC=20 Document: draft-ietf-webdav-rfc2518bis-00.txt A. Faizi, Netscape=20 Expires: Aug 2002 S. Carter, Novell=20 D. Jensen, Novell=20 L. Dusseault, Xythos=20 =20 =20 HTTP Extensions for Distributed Authoring =96 WebDAV RFC2518 bis=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC 2119=20 [RFC2119].=20 =20 Abstract=20 =20 WebDAV consists of a set of methods, headers, and content-types=20 ancillary to HTTP/1.1 for the management of resource properties,=20 creation and management of resource collections, namespace=20 manipulation, and resource locking (collision avoidance).=20 =20 RFC2518 was published in February 1998, and this draft makes only=20 minor revisions mostly due to interoperability experience.=20 =20 =20 Expires Aug 2002 1=20 WebDAV =96 RFC2518 bis February 2002 = =20 Table of Contents=20 =20 =20 1 Introduction...................................................6=20 2 Notational Conventions.........................................7=20 3 Terminology....................................................7=20 4 Data Model for Resource Properties.............................8=20 4.1 The Resource Property Model..................................8=20 4.2 Existing Metadata Proposals..................................9=20 4.3 Properties and HTTP Headers..................................9=20 4.4 Property Values..............................................9=20 4.5 Property Names..............................................10=20 4.6 Media Independent Links.....................................10=20 5 Collections of Web Resources..................................11=20 5.1 HTTP URL Namespace Model....................................11=20 5.2 Collection Resources........................................11=20 5.3 Creation and Retrieval of Collection Resources..............12=20 5.4 Source Resources and Output Resources.......................13=20 6 Locking.......................................................14=20 6.1 Exclusive Vs. Shared Locks..................................14=20 6.2 Required Support............................................15=20 6.3 Lock Tokens.................................................16=20 6.4 opaquelocktoken Lock Token URI Scheme.......................16=20 6.4.1 Node Field Generation Without the IEEE 802 Address..........17=20 6.5 Lock Capability Discovery...................................18=20 6.6 Active Lock Discovery.......................................18=20 6.7 Usage Considerations........................................19=20 7 Write Lock....................................................19=20 7.1 Methods Restricted by Write Locks...........................20=20 7.2 Write Locks and Lock Tokens.................................20=20 7.3 Write Locks and Properties..................................20=20 7.4 Write Locks and Unmapped URLs...............................20=20 7.5 Write Locks and Collections.................................21=20 7.6 Write Locks and the If Request Header.......................22=20 7.6.1 Example - Write Lock........................................22=20 7.7 Write Locks and COPY/MOVE...................................23=20 7.8 Refreshing Write Locks......................................23=20 8 HTTP Methods for Distributed Authoring........................24=20 8.1 PROPFIND....................................................24=20 8.1.1 Example - Retrieving Named Properties.......................25=20 8.1.2 Example - Using propname to Retrieve all Property Names.....27=20 8.2 PROPPATCH...................................................28=20 8.2.1 Status Codes for use with 207 (Multi-Status)................29=20 8.2.2 Example - PROPPATCH.........................................29=20 8.3 MKCOL Method................................................30=20 8.3.1 Request.....................................................30=20 8.3.2 Status Codes................................................31=20 =20 Expires Aug 2002 2=20 WebDAV =96 RFC2518 bis February 2002 = =20 8.3.3 Example - MKCOL.............................................31=20 8.4 GET, HEAD for Collections...................................32=20 8.5 POST for Collections........................................32=20 8.6 DELETE......................................................32=20 8.6.1 DELETE for Non-Collection Resources.........................32=20 8.6.2 DELETE for Collections......................................33=20 8.7 PUT.........................................................34=20 8.7.1 PUT for Non-Collection Resources............................34=20 8.7.2 PUT for Collections.........................................34=20 8.8 COPY Method.................................................34=20 8.8.1 COPY for HTTP/1.1 resources.................................35=20 8.8.2 COPY for Properties.........................................35=20 8.8.3 COPY for Collections........................................35=20 8.8.4 COPY and the Overwrite Header...............................36=20 8.8.5 Status Codes................................................37=20 8.8.6 Example - COPY with Overwrite...............................37=20 8.8.7 Example - COPY with No Overwrite............................37=20 8.8.8 Example - COPY of a Collection..............................38=20 8.9 MOVE Method.................................................39=20 8.9.1 MOVE for Properties.........................................39=20 8.9.2 MOVE for Collections........................................39=20 8.9.3 MOVE and the Overwrite Header...............................40=20 8.9.4 Status Codes................................................40=20 8.9.5 Example - MOVE of a Non-Collection..........................41=20 8.9.6 Example - MOVE of a Collection..............................41=20 8.10 LOCK Method.................................................42=20 8.10.1 Operation..................................................42=20 8.10.2 The Effect of Locks on Properties and Collections..........43=20 8.10.3 Locking Replicated Resources...............................43=20 8.10.4 Depth and Locking..........................................43=20 8.10.5 Interaction with other Methods.............................44=20 8.10.6 Lock Compatibility Table...................................44=20 8.10.7 Status Codes...............................................44=20 8.10.8 Example - Simple Lock Request..............................44=20 8.10.9 Example - Refreshing a Write Lock..........................46=20 8.10.10 Example - Multi-Resource Lock Request.....................47=20 8.11 UNLOCK Method...............................................48=20 8.11.1 Example - UNLOCK...........................................48=20 9 HTTP Headers for Distributed Authoring........................49=20 9.1 DAV Header..................................................49=20 9.2 Depth Header................................................49=20 9.3 Destination Header..........................................50=20 9.4 If Header...................................................50=20 9.4.1 No-tag-list Production......................................51=20 9.4.2 Tagged-list Production......................................52=20 9.4.3 not Production..............................................52=20 9.4.4 Matching Function...........................................53=20 =20 Expires Aug 2002 3=20 WebDAV =96 RFC2518 bis February 2002 = =20 9.4.5 If Header and Non-DAV Compliant Proxies.....................53=20 9.5 Lock-Token Header...........................................53=20 9.6 Overwrite Header............................................53=20 9.7 Status-URI Response Header..................................54=20 9.8 Timeout Request Header......................................54=20 10 Status Code Extensions to HTTP/1.1............................55=20 10.1 102 Processing..............................................55=20 10.2 207 Multi-Status............................................56=20 10.3 422 Unprocessable Entity....................................56=20 10.4 423 Locked..................................................56=20 10.5 424 Failed Dependency.......................................56=20 10.6 507 Insufficient Storage....................................56=20 11 Multi-Status Response.........................................57=20 12 XML Element Definitions.......................................57=20 12.1 activelock XML Element......................................57=20 12.1.1 depth XML Element..........................................57=20 12.1.2 locktoken XML Element......................................57=20 12.1.3 timeout XML Element........................................58=20 12.2 collection XML Element......................................58=20 12.3 href XML Element............................................58=20 12.4 link XML Element............................................58=20 12.4.1 dst XML Element............................................59=20 12.4.2 src XML Element............................................59=20 12.5 lockentry XML Element.......................................59=20 12.6 lockinfo XML Element........................................59=20 12.7 lockscope XML Element.......................................60=20 12.7.1 exclusive XML Element......................................60=20 12.7.2 shared XML Element.........................................60=20 12.8 locktype XML Element........................................60=20 12.8.1 write XML Element..........................................61=20 12.9 multistatus XML Element.....................................61=20 12.9.1 response XML Element.......................................61=20 12.9.2 responsedescription XML Element............................62=20 12.10 owner XML Element..........................................62=20 12.11 prop XML element...........................................62=20 12.12 propertyupdate XML element.................................63=20 12.12.1 remove XML element........................................63=20 12.12.2 set XML element...........................................63=20 12.13 propfind XML Element.......................................64=20 12.13.1 allprop XML Element.......................................64=20 12.13.2 propname XML Element......................................64=20 13 DAV Properties................................................65=20 13.1 creationdate Property.......................................65=20 13.2 displayname Property........................................65=20 13.3 getcontentlanguage Property.................................65=20 13.4 getcontentlength Property...................................66=20 13.5 getcontenttype Property.....................................66=20 =20 Expires Aug 2002 4=20 WebDAV =96 RFC2518 bis February 2002 = =20 13.6 getetag Property............................................66=20 13.7 getlastmodified Property....................................67=20 13.8 lockdiscovery Property......................................67=20 13.8.1 Example - Retrieving the lockdiscovery Property............67=20 13.9 resourcetype Property.......................................68=20 13.10 source Property............................................69=20 13.10.1 Example - A source Property...............................69=20 13.11 supportedlock Property.....................................70=20 13.11.1 Example - Retrieving the supportedlock Property...........70=20 14 Instructions for Processing XML in DAV........................71=20 15 DAV Compliance Classes........................................71=20 15.1 Class 1.....................................................72=20 15.2 Class 2.....................................................72=20 16 Internationalization Considerations...........................72=20 17 Security Considerations.......................................73=20 17.1 Authentication of Clients...................................74=20 17.2 Denial of Service...........................................74=20 17.3 Security through Obscurity..................................75=20 17.4 Privacy Issues Connected to Locks...........................75=20 17.5 Privacy Issues Connected to Properties......................75=20 17.6 Reduction of Security due to Source Link....................75=20 17.7 Implications of XML External Entities.......................76=20 17.8 Risks Connected with Lock Tokens............................76=20 18 IANA Considerations...........................................77=20 19 Intellectual Property.........................................77=20 20 Acknowledgements..............................................78=20 21 References....................................................79=20 21.1 Normative References........................................79=20 21.2 Informational References....................................80=20 22 Authors' Addresses............................................81=20 23 Appendices....................................................82=20 23.1 Appendix 1 - WebDAV Document Type Definition................82=20 23.2 Appendix 2 - ISO 8601 Date and Time Profile.................83=20 23.3 Appendix 3 - Notes on Processing XML Elements...............85=20 23.3.1 Notes on Empty XML Elements................................85=20 23.3.2 Notes on Illegal XML Processing............................85=20 24 Full Copyright Statement......................................87=20 =20 Expires Aug 2002 5=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 1 Introduction=20 =20 This document describes an extension to the HTTP/1.1 protocol that=20 allows clients to perform remote web content authoring operations. =20 This extension provides a coherent set of methods, headers, request=20 entity body formats, and response entity body formats that provide=20 operations for:=20 =20 Properties: The ability to create, remove, and query information=20 about Web pages, such as their authors, creation dates, etc. Also,=20 the ability to link pages of any media type to related pages.=20 =20 Collections: The ability to create sets of documents and to retrieve=20 a hierarchical membership listing (like a directory listing in a=20 file system).=20 =20 Locking: The ability to keep more than one person from working on a=20 document at the same time. This prevents the "lost update problem",=20 in which modifications are lost as first one author then another=20 writes changes without merging the other author's changes.=20 =20 Namespace Operations: The ability to instruct the server to copy and=20 move Web resources.=20 =20 Requirements and rationale for these operations are described in a=20 companion document, "Requirements for a Distributed Authoring and=20 Versioning Protocol for the World Wide Web" [RFC2291].=20 =20 The sections below provide a detailed introduction to resource=20 properties (section 4), collections of resources (section 5), and=20 locking operations (section 6). These sections introduce the=20 abstractions manipulated by the WebDAV-specific HTTP methods=20 described in section 8, "HTTP Methods for Distributed Authoring".=20 =20 In HTTP/1.1, method parameter information was exclusively encoded in=20 HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter=20 information either in an Extensible Markup Language (XML) [REC-XML]=20 request entity body, or in an HTTP header. The use of XML to encode=20 method parameters was motivated by the ability to add extra XML=20 elements to existing structures, providing extensibility; and by=20 XML's ability to encode information in ISO 10646 character sets,=20 providing internationalization support. As a rule of thumb,=20 parameters are encoded in XML entity bodies when they have unbounded=20 length, or when they may be shown to a human user and hence require=20 encoding in an ISO 10646 character set. Otherwise, parameters are=20 encoded within HTTP headers. Section 9 describes the new HTTP=20 headers used with WebDAV methods.=20 =20 In addition to encoding method parameters, XML is used in WebDAV to=20 encode the responses from methods, providing the extensibility and=20 =20 Expires Aug 2002 6=20 WebDAV =96 RFC2518 bis February 2002 = =20 internationalization advantages of XML for method output, as well as=20 input.=20 =20 XML elements used in this specification are defined in section 12.=20 =20 The XML namespace extension is also used in this specification in=20 order to allow for new XML elements to be added without fear of=20 colliding with other element names.=20 =20 While the status codes provided by HTTP/1.1 are sufficient to=20 describe most error conditions encountered by WebDAV methods, there=20 are some errors that do not fall neatly into the existing=20 categories. New status codes developed for the WebDAV methods are=20 defined in section 10. Since some WebDAV methods may operate over=20 many resources, the Multi-Status response has been introduced to=20 return status information for multiple resources. The Multi-Status=20 response is described in section 11.=20 =20 WebDAV employs the property mechanism to store information about the=20 current state of the resource. For example, when a lock is taken=20 out on a resource, a lock information property describes the current=20 state of the lock. Section 13 defines the properties used within the=20 WebDAV specification.=20 =20 Finishing off the specification are sections on what it means to be=20 compliant with this specification (section 15), on=20 internationalization support (section 16), and on security (section=20 17).=20 =20 =20 2 Notational Conventions=20 =20 Since this document describes a set of extensions to the HTTP/1.1=20 protocol, the augmented BNF used herein to describe protocol=20 elements is exactly the same as described in section 2.1 of=20 [RFC2068]. Since this augmented BNF uses the basic production rules=20 provided in section 2.2 of [RFC2068], these rules apply to this=20 document as well.=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC 2119=20 [RFC2119].=20 =20 =20 3 Terminology=20 =20 URI/URL - A Uniform Resource Identifier and Uniform Resource=20 Locator, respectively. These terms (and the distinction between=20 them) are defined in [RFC2396].=20 =20 Collection - A resource that contains a set of URIs, termed member=20 URIs, which identify member resources and meets the requirements in=20 section 5 of this specification.=20 =20 Expires Aug 2002 7=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 Member URI - A URI which is a member of the set of URIs contained by=20 a collection.=20 =20 Internal Member URI - A Member URI that is immediately relative to=20 the URI of the collection (the definition of immediately relative is=20 given in section 5.2).=20 =20 Property - A name/value pair that contains descriptive information=20 about a resource.=20 =20 Live Property - A property whose semantics and syntax are enforced=20 by the server. For example, the live "getcontentlength" property=20 has its value, the length of the entity returned by a GET request,=20 automatically calculated by the server.=20 =20 Dead Property - A property whose semantics and syntax are not=20 enforced by the server. The server only records the value of a dead=20 property; the client is responsible for maintaining the consistency=20 of the syntax and semantics of a dead property.=20 =20 Null Resource - A resource which responds with a 404 (Not Found) to=20 any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. =20 A NULL resource MUST NOT appear as a member of its parent=20 collection.=20 =20 4 Data Model for Resource Properties=20 =20 4.1 The Resource Property Model=20 =20 Properties are pieces of data that describe the state of a resource. = Properties are data about data.=20 =20 Properties are used in distributed authoring environments to provide=20 for efficient discovery and management of resources. For example, a=20 'subject' property might allow for the indexing of all resources by=20 their subject, and an 'author' property might allow for the=20 discovery of what authors have written which documents.=20 =20 The DAV property model consists of name/value pairs. The name of a=20 property identifies the property's syntax and semantics, and=20 provides an address by which to refer to its syntax and semantics.=20 =20 There are two categories of properties: "live" and "dead". A live=20 property has its syntax and semantics enforced by the server. Live=20 properties include cases where a) the value of a property is read- only, maintained by the server, and b) the value of the property is=20 maintained by the client, but the server performs syntax checking on=20 submitted values. All instances of a given live property MUST comply=20 with the definition associated with that property name. A dead=20 property has its syntax and semantics enforced by the client; the=20 server merely records the value of the property verbatim.=20 =20 Expires Aug 2002 8=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 4.2 Existing Metadata Proposals=20 =20 Properties have long played an essential role in the maintenance of=20 large document repositories, and many current proposals contain some=20 notion of a property, or discuss web metadata more generally. These=20 include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several=20 proposals on representing relationships within HTML. Work on PICS-NG=20 and Web Collections has been subsumed by the Resource Description=20 Framework (RDF) metadata activity of the World Wide Web Consortium.=20 RDF consists of a network-based data model and an XML representation=20 of that model.=20 =20 Some proposals come from a digital library perspective. These=20 include the Dublin Core [RFC2413] metadata set and the Warwick=20 Framework [WF], a container architecture for different metadata=20 schemas. The literature includes many examples of metadata,=20 including MARC [USMARC], a bibliographic metadata format, and a=20 technical report bibliographic format employed by the Dienst system=20 [RFC1807]. Additionally, the proceedings from the first IEEE=20 Metadata conference describe many community-specific metadata sets.=20 =20 Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],=20 noted that "new metadata sets will develop as the networked=20 infrastructure matures" and "different communities will propose,=20 design, and be responsible for different types of metadata." These=20 observations can be corroborated by noting that many community- specific sets of metadata already exist, and there is significant=20 motivation for the development of new forms of metadata as many=20 communities increasingly make their data available in digital form,=20 requiring a metadata format to assist data location and cataloging.=20 =20 4.3 Properties and HTTP Headers=20 =20 Properties already exist, in a limited sense, in HTTP message=20 headers. However, in distributed authoring environments a=20 relatively large number of properties are needed to describe the=20 state of a resource, and setting/returning them all through HTTP=20 headers is inefficient. Thus a mechanism is needed which allows a=20 principal to identify a set of properties in which the principal is=20 interested and to set or retrieve just those properties.=20 =20 4.4 Property Values=20 =20 The value of a property when expressed in XML MUST be well formed.=20 =20 XML has been chosen because it is a flexible, self-describing,=20 structured data format that supports rich schema definitions, and=20 because of its support for multiple character sets. XML's self- =20 Expires Aug 2002 9=20 WebDAV =96 RFC2518 bis February 2002 = =20 describing nature allows any property's value to be extended by=20 adding new elements. Older clients will not break when they=20 encounter extensions because they will still have the data specified=20 in the original schema and will ignore elements they do not=20 understand. XML's support for multiple character sets allows any=20 human-readable property to be encoded and read in a character set=20 familiar to the user. XML's support for multiple human languages,=20 using the "xml:lang" attribute (in the case of WebDAV properties,=20 this attribute is placed on the =91prop=92 element), handles cases = where=20 the same character set is employed by multiple human languages.=20 =20 4.5 Property Names=20 =20 A property name is a universally unique identifier that is=20 associated with a schema that provides information about the syntax=20 and semantics of the property.=20 =20 Because a property's name is universally unique, clients can depend=20 upon consistent behavior for a particular property across multiple=20 resources, on the same and across different servers, so long as that=20 property is "live" on the resources in question, and the=20 implementation of the live property is faithful to its definition.=20 =20 The XML namespace mechanism, which is based on URIs [RFC2396], is=20 used to name properties because it prevents namespace collisions and=20 provides for varying degrees of administrative control.=20 =20 The property namespace is flat; that is, no hierarchy of properties=20 is explicitly recognized. Thus, if a property A and a property A/B=20 exist on a resource, there is no recognition of any relationship=20 between the two properties. It is expected that a separate=20 specification will eventually be produced which will address issues=20 relating to hierarchical properties.=20 =20 Finally, it is not possible to define the same property twice on a=20 single resource, as this would cause a collision in the resource's=20 property namespace.=20 =20 4.6 Media Independent Links=20 =20 Although HTML resources support links to other resources, the Web=20 needs more general support for links between resources of any media=20 type (media types are also known as MIME types, or content types). =20 WebDAV provides such links. A WebDAV link is a special type of=20 property value, formally defined in section Error! Reference source=20 not found., that allows typed connections to be established between=20 resources of any media type. The property value consists of source=20 and destination Uniform Resource Identifiers (URIs); the property=20 name identifies the link type.=20 =20 =20 =20 Expires Aug 2002 10=20 WebDAV =96 RFC2518 bis February 2002 = =20 5 Collections of Web Resources=20 =20 This section provides a description of a new type of Web resource,=20 the collection, and discusses its interactions with the HTTP URL=20 namespace. The purpose of a collection resource is to model=20 collection-like objects (e.g., file system directories) within a=20 server's namespace.=20 =20 All DAV compliant resources MUST support the HTTP URL namespace=20 model specified herein.=20 =20 5.1 HTTP URL Namespace Model=20 =20 The HTTP URL namespace is a hierarchical namespace where the=20 hierarchy is delimited with the "/" character. =20 =20 An HTTP URL namespace is said to be consistent if it meets the=20 following conditions: for every URL in the HTTP hierarchy there=20 exists a collection that contains that URL as an internal member.=20 The root, or top-level collection of the namespace under=20 consideration is exempt from the previous rule.=20 =20 Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL=20 namespace be consistent. However, certain WebDAV methods are=20 prohibited from producing results that cause namespace=20 inconsistencies.=20 =20 Although implicit in [RFC2068] and [RFC2396], any resource,=20 including collection resources, MAY be identified by more than one=20 URI. For example, a resource could be identified by multiple HTTP=20 URLs.=20 =20 5.2 Collection Resources=20 =20 A collection is a resource whose state consists of at least a list=20 of internal member URIs and a set of properties, but which may have=20 additional state such as entity bodies returned by GET. An internal=20 member URI MUST be immediately relative to a base URI of the=20 collection. That is, the internal member URI is equal to a=20 containing collection's URI plus an additional segment for non- collection resources, or additional segment plus trailing slash "/"=20 for collection resources, where segment is defined in section 3.3 of=20 [RFC2396]. =20 =20 Any given internal member URI MUST only belong to the collection=20 once, i.e., it is illegal to have multiple instances of the same URI=20 in a collection. Properties defined on collections behave exactly=20 as do properties on non-collection resources. =20 =20 =20 Expires Aug 2002 11=20 WebDAV =96 RFC2518 bis February 2002 = =20 For all WebDAV compliant resources A and B, identified by URIs U and=20 V, for which U is immediately relative to V, B MUST be a collection=20 that has U as an internal member URI. So, if the resource with URL=20 http://foo.com/bar/blah is WebDAV compliant and if the resource with=20 URL http://foo.com/bar/ is WebDAV compliant then the resource with=20 URL http://foo.com/bar/ must be a collection and must contain URL=20 http://foo.com/bar/blah as an internal member.=20 =20 Collection resources MAY list the URLs of non-WebDAV compliant=20 children in the HTTP URL namespace hierarchy as internal members but=20 are not required to do so. For example, if the resource with URL=20 http://foo.com/bar/blah is not WebDAV compliant and the URL=20 http://foo.com/bar/ identifies a collection then URL=20 http://foo.com/bar/blah may or may not be an internal member of the=20 collection with URL http://foo.com/bar/.=20 =20 If a WebDAV compliant resource has no WebDAV compliant children in=20 the HTTP URL namespace hierarchy then the WebDAV compliant resource=20 is not required to be a collection.=20 =20 There is a standing convention that when a collection is referred to=20 by its name without a trailing slash, the trailing slash is=20 automatically appended. Due to this, a resource may accept a URI=20 without a trailing "/" to point to a collection. In this case it=20 SHOULD return a Content-Location header in the response pointing to=20 the URI ending with the "/". For example, if a client invokes a=20 method on http://foo.bar/blah (no trailing slash), the resource=20 http://foo.bar/blah/ (trailing slash) may respond as if the=20 operation were invoked on it, and should return a content-location=20 header with http://foo.bar/blah/ in it. In general clients SHOULD=20 use the "/" form of collection names.=20 =20 A resource MAY be a collection but not be WebDAV compliant. That=20 is, the resource may comply with all the rules set out in this=20 specification regarding how a collection is to behave without=20 necessarily supporting all methods that a WebDAV compliant resource=20 is required to support. In such a case the resource may return the=20 DAV:resourcetype property with the value DAV:collection but MUST NOT=20 return a DAV header containing the value "1" on an OPTIONS response. = =20 =20 Clients MUST be able to support the case where WebDAV resources are=20 contained inside non-WebDAV resources. For example, if a OPTIONS=20 response from "http://foo.bar/servlet/dav/collection" indicates=20 WebDAV support, the client cannot assume that=20 "http://foo.bar/servlet/dav/" or its parent necessarily are WebDAV=20 collections.=20 =20 5.3 Creation and Retrieval of Collection Resources=20 =20 This document specifies the MKCOL method to create new collection=20 resources, rather than using the existing HTTP/1.1 PUT or POST=20 method, for the following reasons:=20 =20 Expires Aug 2002 12=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 In HTTP/1.1, the PUT method is defined to store the request body at=20 the location specified by the Request-URI. While a description=20 format for a collection can readily be constructed for use with PUT,=20 the implications of sending such a description to the server are=20 undesirable. For example, if a description of a collection that=20 omitted some existing resources were PUT to a server, this might be=20 interpreted as a command to remove those members. This would extend=20 PUT to perform DELETE functionality, which is undesirable since it=20 changes the semantics of PUT, and makes it difficult to control=20 DELETE functionality with an access control scheme based on methods.=20 =20 While the POST method is sufficiently open-ended that a "create a=20 collection" POST command could be constructed, this is undesirable=20 because it would be difficult to separate access control for=20 collection creation from other uses of POST.=20 =20 The exact definition of the behavior of GET and PUT on collections=20 is defined later in this document.=20 =20 5.4 Source Resources and Output Resources=20 =20 For many resources, the entity returned by a GET method exactly=20 matches the persistent state of the resource, for example, a GIF=20 file stored on a disk. For this simple case, the URI at which a=20 resource is accessed is identical to the URI at which the source=20 (the persistent state) of the resource is accessed. This is also=20 the case for HTML source files that are not processed by the server=20 prior to transmission.=20 =20 However, the server can sometimes process HTML resources before they=20 are transmitted as a return entity body. For example, a server- side-include directive within an HTML file might instruct a server=20 to replace the directive with another value, such as the current=20 date. In this case, what is returned by GET (HTML plus date)=20 differs from the persistent state of the resource (HTML plus=20 directive). Typically there is no way to access the HTML resource=20 containing the unprocessed directive.=20 =20 Sometimes the entity returned by GET is the output of a data- producing process that is described by one or more source resources=20 (that may not even have a location in the URI namespace). A single=20 data-producing process may dynamically generate the state of a=20 potentially large number of output resources. An example of this is=20 a CGI script that describes a "finger" gateway process that maps=20 part of the namespace of a server into finger requests, such as=20 http://www.foo.bar.org/finger_gateway/user@host.=20 =20 In the absence of distributed authoring capabilities, it is=20 acceptable to have no mapping of source resource(s) to the URI=20 namespace. In fact, preventing access to the source resource(s) has=20 desirable security benefits. However, if remote editing of the=20 =20 Expires Aug 2002 13=20 WebDAV =96 RFC2518 bis February 2002 = =20 source resource(s) is desired, the source resource(s) should be=20 given a location in the URI namespace. This source location should=20 not be one of the locations at which the generated output is=20 retrievable, since in general it is impossible for the server to=20 differentiate requests for source resources from requests for=20 process output resources. There is often a many-to-many=20 relationship between source resources and output resources.=20 =20 On WebDAV compliant servers the URI of the source resource(s) may be=20 stored in a link on the output resource with type DAV:source (see=20 section 13.10 for a description of the source link property). =20 Storing the source URIs in links on the output resources places the=20 burden of discovering the source on the authoring client. Note that=20 the value of a source link is not guaranteed to point to the correct=20 source. Source links may break or incorrect values may be entered. =20 Also note that not all servers will allow the client to set the=20 source link value. For example a server which generates source=20 links on the fly for its CGI files will most likely not allow a=20 client to set the source link value.=20 =20 6 Locking=20 =20 The ability to lock a resource provides a mechanism for serializing=20 access to that resource. Using a lock, an authoring client can=20 provide a reasonable guarantee that another principal will not=20 modify a resource while it is being edited. In this way, a client=20 can prevent the "lost update" problem.=20 =20 This specification allows locks to vary over two client-specified=20 parameters, the number of principals involved (exclusive vs. shared)=20 and the type of access to be granted. This document defines locking=20 for only one access type, write. However, the syntax is extensible,=20 and permits the eventual specification of locking for other access=20 types.=20 =20 6.1 Exclusive Vs. Shared Locks=20 =20 The most basic form of lock is an exclusive lock. This is a lock=20 where the access right in question is only granted to a single=20 principal. The need for this arbitration results from a desire to=20 avoid having to merge results.=20 =20 However, there are times when the goal of a lock is not to exclude=20 others from exercising an access right but rather to provide a=20 mechanism for principals to indicate that they intend to exercise=20 their access rights. Shared locks are provided for this case. A=20 shared lock allows multiple principals to receive a lock. Hence any=20 principal with appropriate access can get the lock.=20 =20 With shared locks there are two trust sets that affect a resource. =20 The first trust set is created by access permissions. Principals=20 =20 Expires Aug 2002 14=20 WebDAV =96 RFC2518 bis February 2002 = =20 who are trusted, for example, may have permission to write to the=20 resource. Among those who have access permission to write to the=20 resource, the set of principals who have taken out a shared lock=20 also must trust each other, creating a (typically) smaller trust set=20 within the access permission write set.=20 =20 Starting with every possible principal on the Internet, in most=20 situations the vast majority of these principals will not have write=20 access to a given resource. Of the small number who do have write=20 access, some principals may decide to guarantee their edits are free=20 from overwrite conflicts by using exclusive write locks. Others may=20 decide they trust their collaborators will not overwrite their work=20 (the potential set of collaborators being the set of principals who=20 have write permission) and use a shared lock, which informs their=20 collaborators that a principal may be working on the resource.=20 =20 The WebDAV extensions to HTTP do not need to provide all of the=20 communications paths necessary for principals to coordinate their=20 activities. When using shared locks, principals may use any out of=20 band communication channel to coordinate their work (e.g., face-to- face interaction, written notes, post-it notes on the screen,=20 telephone conversation, Email, etc.) The intent of a shared lock is=20 to let collaborators know who else may be working on a resource.=20 =20 Shared locks are included because experience from web distributed=20 authoring systems has indicated that exclusive locks are often too=20 rigid. An exclusive lock is used to enforce a particular editing=20 process: take out an exclusive lock, read the resource, perform=20 edits, write the resource, release the lock. This editing process=20 has the problem that locks are not always properly released, for=20 example when a program crashes, or when a lock owner leaves without=20 unlocking a resource. While both timeouts and administrative action=20 can be used to remove an offending lock, neither mechanism may be=20 available when needed; the timeout may be long or the administrator=20 may not be available.=20 =20 6.2 Required Support=20 =20 A WebDAV compliant server is not required to support locking in any=20 form. If the server does support locking it may choose to support=20 any combination of exclusive and shared locks for any access types.=20 =20 The reason for this flexibility is that locking policy strikes to=20 the very heart of the resource management and versioning systems=20 employed by various storage repositories. These repositories=20 require control over what sort of locking will be made available. =20 For example, some repositories only support shared write locks while=20 others only provide support for exclusive write locks while yet=20 others use no locking at all. As each system is sufficiently=20 different to merit exclusion of certain locking features, this=20 specification leaves locking as the sole axis of negotiation within=20 WebDAV.=20 =20 Expires Aug 2002 15=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 6.3 Lock Tokens=20 =20 A lock token is a type of state token, represented as a URI, which=20 identifies a particular lock. A lock token is returned by every=20 successful LOCK operation in the lockdiscovery property in the=20 response body, and can also be found through lock discovery on a=20 resource.=20 =20 Lock token URIs MUST be unique across all resources for all time.=20 This uniqueness constraint allows lock tokens to be submitted across=20 resources and servers without fear of confusion.=20 =20 This specification provides a lock token URI scheme called=20 opaquelocktoken that meets the uniqueness requirements. However=20 resources are free to return any URI scheme so long as it meets the=20 uniqueness requirements.=20 =20 Having a lock token provides no special access rights. Anyone can=20 find out anyone else's lock token by performing lock discovery.=20 Locks MUST be enforced based upon whatever authentication mechanism=20 is used by the server, not based on the secrecy of the token values.=20 =20 6.4 opaquelocktoken Lock Token URI Scheme=20 =20 The opaquelocktoken URI scheme is designed to be unique across all=20 resources for all time. Due to this uniqueness quality, a client=20 may submit an opaque lock token in an If header on a resource other=20 than the one that returned it.=20 =20 All resources MUST recognize the opaquelocktoken scheme and, at=20 minimum, recognize that the lock token does not refer to an=20 outstanding lock on the resource.=20 =20 In order to guarantee uniqueness across all resources for all time=20 the opaquelocktoken requires the use of the Universal Unique=20 Identifier (UUID) mechanism, as described in [ISO-11578].=20 =20 Opaquelocktoken generators, however, have a choice of how they=20 create these tokens. They can either generate a new UUID for every=20 lock token they create or they can create a single UUID and then=20 add extension characters. If the second method is selected then the=20 program generating the extensions MUST guarantee that the same=20 extension will never be used twice with the associated UUID.=20 =20 OpaqueLockToken-URI =3D "opaquelocktoken:" UUID [Extension] ; The=20 UUID production is the string representation of a UUID, as defined=20 in [ISO-11578]. Note that white space (LWS) is not allowed between=20 elements of this production.=20 =20 =20 Expires Aug 2002 16=20 WebDAV =96 RFC2518 bis February 2002 = =20 Extension =3D path ; path is defined in section 3.2.1 of RFC 2068=20 [RFC2068]=20 =20 6.4.1 Node Field Generation Without the IEEE 802 Address=20 =20 UUIDs, as defined in [ISO-11578], contain a "node" field that=20 contains one of the IEEE 802 addresses for the server machine. As=20 noted in section 17, there are several security risks associated=20 with exposing a machine's IEEE 802 address. This section provides an=20 alternate mechanism for generating the "node" field of a UUID which=20 does not employ an IEEE 802 address. WebDAV servers MAY use this=20 algorithm for creating the node field when generating UUIDs. The=20 text in this section is originally from an Internet-Draft by Paul=20 Leach and Rich Salz, who are noted here to properly attribute their=20 work.=20 =20 The ideal solution is to obtain a 47 bit cryptographic quality=20 random number, and use it as the low 47 bits of the node ID, with=20 the most significant bit of the first octet of the node ID set to 1.=20 This bit is the unicast/multicast bit, which will never be set in=20 IEEE 802 addresses obtained from network cards; hence, there can=20 never be a conflict between UUIDs generated by machines with and=20 without network cards.=20 =20 If a system does not have a primitive to generate cryptographic=20 quality random numbers, then in most systems there are usually a=20 fairly large number of sources of randomness available from which=20 one can be generated. Such sources are system specific, but often=20 include:=20 =20 - the percent of memory in use=20 - the size of main memory in bytes=20 - the amount of free main memory in bytes=20 - the size of the paging or swap file in bytes=20 - free bytes of paging or swap file=20 - the total size of user virtual address space in bytes=20 - the total available user address space bytes=20 - the size of boot disk drive in bytes=20 - the free disk space on boot drive in bytes=20 - the current time=20 - the amount of time since the system booted=20 - the individual sizes of files in various system directories=20 - the creation, last read, and modification times of files in =20 various system directories=20 - the utilization factors of various system resources (heap, etc.)=20 - current mouse cursor position=20 - current caret position=20 - current number of running processes, threads=20 - handles or IDs of the desktop window and the active window=20 - the value of stack pointer of the caller=20 - the process and thread ID of caller=20 - various processor architecture specific performance counters=20 =20 Expires Aug 2002 17=20 WebDAV =96 RFC2518 bis February 2002 = =20 (instructions executed, cache misses, TLB misses)=20 =20 (Note that it is precisely the above kinds of sources of randomness=20 that are used to seed cryptographic quality random number generators=20 on systems without special hardware for their construction.)=20 =20 In addition, items such as the computer's name and the name of the=20 operating system, while not strictly speaking random, will help=20 differentiate the results from those obtained by other systems.=20 =20 The exact algorithm to generate a node ID using these data is system=20 specific, because both the data available and the functions to=20 obtain them are often very system specific. However, assuming that=20 one can concatenate all the values from the randomness sources into=20 a buffer, and that a cryptographic hash function such as MD5 is=20 available, then any 6 bytes of the MD5 hash of the buffer, with the=20 multicast bit (the high bit of the first byte) set will be an=20 appropriately random node ID.=20 =20 Other hash functions, such as SHA-1, can also be used. The only=20 requirement is that the result be suitably random _ in the sense=20 that the outputs from a set uniformly distributed inputs are=20 themselves uniformly distributed, and that a single bit change in=20 the input can be expected to cause half of the output bits to=20 change.=20 =20 6.5 Lock Capability Discovery=20 =20 Since server lock support is optional, a client trying to lock a=20 resource on a server can either try the lock and hope for the best,=20 or perform some form of discovery to determine what lock=20 capabilities the server supports. This is known as lock capability=20 discovery. Lock capability discovery differs from discovery of=20 supported access control types, since there may be access control=20 types without corresponding lock types. A client can determine what=20 lock types the server supports by retrieving the supportedlock=20 property.=20 =20 Any DAV compliant resource that supports the LOCK method MUST=20 support the supportedlock property.=20 =20 6.6 Active Lock Discovery=20 =20 If another principal locks a resource that a principal wishes to=20 access, it is useful for the second principal to be able to find out=20 who the first principal is. For this purpose the lockdiscovery=20 property is provided. This property lists all outstanding locks,=20 describes their type, and where available, provides their lock=20 token.=20 =20 =20 Expires Aug 2002 18=20 WebDAV =96 RFC2518 bis February 2002 = =20 Any DAV compliant resource that supports the LOCK method MUST=20 support the lockdiscovery property.=20 =20 6.7 Usage Considerations=20 =20 Although the locking mechanisms specified here provide some help in=20 preventing lost updates, they cannot guarantee that updates will=20 never be lost. Consider the following scenario:=20 =20 Two clients A and B are interested in editing the resource=20 'index.html'. Client A is an HTTP client rather than a WebDAV=20 client, and so does not know how to perform locking.=20 =20 Client A doesn't lock the document, but does a GET and begins=20 editing.=20 Client B does LOCK, performs a GET and begins editing.=20 Client B finishes editing, performs a PUT, then an UNLOCK.=20 Client A performs a PUT, overwriting and losing all of B's changes.=20 =20 There are several reasons why the WebDAV protocol itself cannot=20 prevent this situation. First, it cannot force all clients to use=20 locking because it must be compatible with HTTP clients that do not=20 comprehend locking. Second, it cannot require servers to support=20 locking because of the variety of repository implementations, some=20 of which rely on reservations and merging rather than on locking. =20 Finally, being stateless, it cannot enforce a sequence of operations=20 like LOCK / GET / PUT / UNLOCK. =20 =20 WebDAV servers that support locking can reduce the likelihood that=20 clients will accidentally overwrite each other's changes by=20 requiring clients to lock resources before modifying them. Such=20 servers would effectively prevent HTTP 1.0 and HTTP 1.1 clients from=20 modifying resources.=20 =20 WebDAV clients can be good citizens by using a lock / retrieve /=20 write /unlock sequence of operations (at least by default) whenever=20 they interact with a WebDAV server that supports locking.=20 =20 HTTP 1.1 clients can be good citizens, avoiding overwriting other=20 clients' changes, by using entity tags in If-Match headers with any=20 requests that would modify resources. =20 =20 Information managers may attempt to prevent overwrites by=20 implementing client-side procedures requiring locking before=20 modifying WebDAV resources.=20 =20 =20 7 Write Lock=20 =20 =20 Expires Aug 2002 19=20 WebDAV =96 RFC2518 bis February 2002 = =20 This section describes the semantics specific to the write lock=20 type. The write lock is a specific instance of a lock type, and is=20 the only lock type described in this specification.=20 =20 7.1 Methods Restricted by Write Locks=20 =20 A write lock MUST prevent a principal without the lock from=20 successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,=20 DELETE, or MKCOL on the locked resource. All other current methods,=20 GET in particular, function independently of the lock.=20 =20 Note, however, that as new methods are created it will be necessary=20 to specify how they interact with a write lock.=20 =20 7.2 Write Locks and Lock Tokens=20 =20 A successful request for an exclusive or shared write lock MUST=20 result in the generation of a unique lock token associated with the=20 requesting principal. Thus if five principals have a shared write=20 lock on the same resource there will be five lock tokens, one for=20 each principal.=20 =20 7.3 Write Locks and Properties=20 =20 While those without a write lock may not alter a property on a=20 resource it is still possible for the values of live properties to=20 change, even while locked, due to the requirements of their schemas. = Only dead properties and live properties defined to respect locks=20 are guaranteed not to change while write locked.=20 =20 7.4 Write Locks and Unmapped URLs=20 =20 It is possible to lock an unmapped URL in order to lock the name for=20 use. This is a simple way to avoid the lost-update problem on the=20 creation of a new resource (another way is to use If-None-Match=20 header specified in HTTP 1.1). It has the side benefit of locking=20 the new resource immediately for use of the creator. =20 =20 The lost-update problem is not an issue for collections because=20 MKCOL can only be used to create a collection, not to overwrite an=20 existing collection. In order to immediately lock a collection upon=20 creation, clients may attempt to pipeline the MKCOL and LOCK=20 requests together. =20 =20 A lock request to an unmapped URL should result in the creation of a=20 resource that is locked. A subsequent PUT request with the correct=20 lock token should normally succeed, and provides the content,=20 content-type, content-language and other information as appropriate. = =20 Expires Aug 2002 20=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 In this situation, WebDAV servers compliant with RFC2518 MAY create=20 "lock-null" resources which are special and unusual resources. A=20 lock-null resource:=20 =20 - responds with a 404 or 405 to any DAV method except for PUT,=20 MKCOL, OPTIONS, PROPFIND, LOCK, UNLOCK.=20 - Appears as a member of its parent collection.=20 - Disappears (becomes once more an unmapped URL) if its lock goes=20 away before it is converted to a regular resource. (This must=20 also happen if it is renamed or moved, or if any parent collection=20 is renamed or moved, because locks are tied to URLs).=20 - May be turned into a regular resource when a PUT request to the=20 URL is successful. Ceases to be a lock-null resource.=20 - May be turned into a collection when a MKCOL request to the URL is=20 successful. Ceases to be a lock-null resource=20 - Has defined values for lockdiscovery and supportedlock properties.=20 =20 However, interoperability and compliance problems have been found=20 with lock-null resources. Therefore, they are deprecated. WebDAV=20 servers compliant with this document SHOULD create regular locked=20 empty resources, which behave in every way as if they were a normal=20 resource. A locked empty resource:=20 =20 - Can be downloaded, deleted, moved, copied, and in all ways behave=20 as a regular resource, not a lock-null resource.=20 - Appears as a member of its parent collection.=20 - SHOULD NOT disappear when its lock goes away (clients must=20 therefore be responsible for cleaning up their own mess, as with=20 any other operation)=20 - SHOULD default to a content-type of "application/octet-stream".=20 - SHOULD default to reasonable, or reasonably blank, values for=20 other properties like getcontentlanguage.=20 - May have content added with a PUT request. MUST be able to change=20 content type.=20 - MUST NOT be turned into a collection. A MKCOL request must fail=20 as it would to any existing resource.=20 - MUST have defined values for lockdiscovery and supportedlock=20 properties.=20 - The response MUST indicate that a resource was created, by use of=20 the "201 Created" response code (a LOCK request to an existing=20 resource instead will result in 200 OK). The body must still=20 include the lockdiscovery property, as with a LOCK request to an=20 existing resource.=20 =20 Clients can easily interoperate with either kind of server (both=20 exist) by only attempting PUT after a LOCK to an unmapped URL, not=20 MKCOL or GET.=20 =20 7.5 Write Locks and Collections=20 =20 =20 Expires Aug 2002 21=20 WebDAV =96 RFC2518 bis February 2002 = =20 A write lock on a collection, whether created by a "Depth: 0" or=20 "Depth: infinity" lock request, prevents the addition or removal of=20 member URIs of the collection by non-lock owners. As a consequence,=20 when a principal issues a PUT or POST request to create a new=20 resource under a URI which needs to be an internal member of a write=20 locked collection to maintain HTTP namespace consistency, or issues=20 a DELETE to remove a resource which has a URI which is an existing=20 internal member URI of a write locked collection, this request MUST=20 fail if the principal does not have a write lock on the collection.=20 =20 However, if a write lock request is issued to a collection=20 containing member URIs identifying resources that are currently=20 locked in a manner which conflicts with the write lock, the request=20 MUST fail with a 423 (Locked) status code.=20 =20 If a lock owner causes the URI of a resource to be added as an=20 internal member URI of a locked collection then the new resource=20 MUST be automatically added to the lock. This is the only mechanism=20 that allows a resource to be added to a write lock. Thus, for=20 example, if the collection /a/b/ is write locked and the resource /c=20 is moved to /a/b/c then resource /a/b/c will be added to the write=20 lock.=20 =20 7.6 Write Locks and the If Request Header=20 =20 If a user agent is not required to have knowledge about a lock when=20 requesting an operation on a locked resource, the following scenario=20 might occur. Program A, run by User A, takes out a write lock on a=20 resource. Program B, also run by User A, has no knowledge of the=20 lock taken out by Program A, yet performs a PUT to the locked=20 resource. In this scenario, the PUT succeeds because locks are=20 associated with a principal, not a program, and thus program B,=20 because it is acting with principal A=92s credential, is allowed to=20 perform the PUT. However, had program B known about the lock, it=20 would not have overwritten the resource, preferring instead to=20 present a dialog box describing the conflict to the user. Due to=20 this scenario, a mechanism is needed to prevent different programs=20 from accidentally ignoring locks taken out by other programs with=20 the same authorization.=20 =20 In order to prevent these collisions a lock token MUST be submitted=20 by an authorized principal in the If header for all locked resources=20 that a method may interact with or the method MUST fail. For=20 example, if a resource is to be moved and both the source and=20 destination are locked then two lock tokens must be submitted, one=20 for the source and the other for the destination.=20 =20 7.6.1 Example - Write Lock=20 =20 >>Request=20 =20 =20 Expires Aug 2002 22=20 WebDAV =96 RFC2518 bis February 2002 = =20 COPY /~fielding/index.html HTTP/1.1=20 Host: www.ics.uci.edu=20 Destination: http://www.ics.uci.edu/users/f/fielding/index.html=20 If: =20 ()=20 =20 =20 >>Response=20 =20 HTTP/1.1 204 No Content=20 =20 =20 In this example, even though both the source and destination are=20 locked, only one lock token must be submitted, for the lock on the=20 destination. This is because the source resource is not modified by=20 a COPY, and hence unaffected by the write lock. In this example,=20 user agent authentication has previously occurred via a mechanism=20 outside the scope of the HTTP protocol, in the underlying transport=20 layer.=20 =20 7.7 Write Locks and COPY/MOVE=20 =20 A COPY method invocation MUST NOT duplicate any write locks active=20 on the source. However, as previously noted, if the COPY copies the=20 resource into a collection that is locked with "Depth: infinity",=20 then the resource will be added to the lock.=20 =20 A successful MOVE request on a write locked resource MUST NOT move=20 the write lock with the resource. However, the resource is subject=20 to being added to an existing lock at the destination, as specified=20 in section 7.5. For example, if the MOVE makes the resource a child=20 of a collection that is locked with "Depth: infinity", then the=20 resource will be added to that collection's lock. Additionally, if a=20 resource locked with "Depth: infinity" is moved to a destination=20 that is within the scope of the same lock (e.g., within the=20 namespace tree covered by the lock), the moved resource will again=20 be a added to the lock. In both these examples, as specified in=20 section 7.6, an If header must be submitted containing a lock token=20 for both the source and destination. =20 =20 7.8 Refreshing Write Locks=20 =20 A client MUST NOT submit the same write lock request twice. Note=20 that a client is always aware it is resubmitting the same lock=20 request because it must include the lock token in the If header in=20 order to make the request for a resource that is already locked.=20 =20 However, a client may submit a LOCK method with an If header but=20 without a body. This form of LOCK MUST only be used to "refresh" a=20 =20 Expires Aug 2002 23=20 WebDAV =96 RFC2518 bis February 2002 = =20 lock. Meaning, at minimum, that any timers associated with the lock=20 MUST be re-set.=20 =20 A server may return a Timeout header with a lock refresh that is=20 different than the Timeout header returned when the lock was=20 originally requested. Additionally clients may submit Timeout=20 headers of arbitrary value with their lock refresh requests. =20 Servers, as always, may ignore Timeout headers submitted by the=20 client.=20 =20 If an error is received in response to a refresh LOCK request the=20 client SHOULD assume that the lock was not refreshed.=20 =20 8 HTTP Methods for Distributed Authoring=20 =20 The following new HTTP methods use XML as a request and response=20 format. All DAV compliant clients and resources MUST use XML=20 parsers that are compliant with [REC-XML]. All XML used in either=20 requests or responses MUST be, at minimum, well formed. If a server=20 receives ill-formed XML in a request it MUST reject the entire=20 request with a 400 (Bad Request). If a client receives ill-formed=20 XML in a response then it MUST NOT assume anything about the outcome=20 of the executed method and SHOULD treat the server as=20 malfunctioning.=20 =20 8.1 PROPFIND=20 =20 The PROPFIND method retrieves properties defined on the resource=20 identified by the Request-URI, if the resource does not have any=20 internal members, or on the resource identified by the Request-URI=20 and potentially its member resources, if the resource is a=20 collection that has internal member URIs. All DAV compliant=20 resources MUST support the PROPFIND method and the propfind XML=20 element (section Error! Reference source not found.) along with all=20 XML elements defined for use with that element.=20 =20 A client may submit a Depth header with a value of "0", "1", or=20 "infinity" with a PROPFIND on a collection resource with internal=20 member URIs. DAV compliant servers MUST support the "0", "1" and=20 "infinity" behaviors. By default, the PROPFIND method without a=20 Depth header MUST act as if a "Depth: infinity" header was included.=20 =20 A client may submit a propfind XML element in the body of the=20 request method describing what information is being requested. It=20 is possible to request particular property values, all property=20 values, or a list of the names of the resource=92s properties. A=20 client may choose not to submit a request body. An empty PROPFIND=20 request body MUST be treated as a request for the names and values=20 of all properties. =20 =20 =20 Expires Aug 2002 24=20 WebDAV =96 RFC2518 bis February 2002 = =20 Clients MUST not send allprop requests in any form (either the empty=20 body PROPFIND or the specific allprop element), because allprop is=20 being removed. WebDAV servers increasingly have expensively- calculated or lengthy properties (see DeltaV and ACL specifications=20 [TODO: ref RFC when available]) and do not return all properties=20 already. Instead, WebDAV clients can use propname requests to=20 discover what properties exist, and request named properties when=20 retrieving values. A WebDAV server MAY omit certain live properties=20 from other specifications when responding to an allprop request from=20 an older client, and MAY return only custom (dead) properties and=20 those defined in this specification.=20 =20 All servers MUST support returning a response of content type=20 text/xml or application/xml that contains a multistatus XML element=20 that describes the results of the attempts to retrieve the various=20 properties.=20 =20 If there is an error retrieving a property then a proper error=20 result MUST be included in the response. A request to retrieve the=20 value of a property which does not exist is an error and MUST be=20 noted, if the response uses a multistatus XML element, with a=20 response XML element which contains a 404 (Not Found) status value.=20 =20 Consequently, the multistatus XML element for a collection resource=20 with member URIs MUST include a response XML element for each member=20 URI of the collection, to whatever depth was requested. Each=20 response XML element MUST contain an href XML element that gives the=20 URI of the resource on which the properties in the prop XML element=20 are defined. Results for a PROPFIND on a collection resource with=20 internal member URIs are returned as a flat list whose order of=20 entries is not significant.=20 =20 In the case of allprop and propname, if a principal does not have=20 the right to know whether a particular property exists then the=20 property should be silently excluded from the response.=20 =20 The results of this method SHOULD NOT be cached.=20 =20 8.1.1 Example - Retrieving Named Properties=20 =20 >>Request=20 =20 PROPFIND /file HTTP/1.1=20 Host: www.foo.bar=20 Content-type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 =20 =20 Expires Aug 2002 25=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 =20 =20 =20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 http://www.foo.bar/file=20 =20 =20 =20 Box type A=20 =20 =20 J.J. Johnson=20 =20 =20 HTTP/1.1 200 OK=20 =20 =20 =20 HTTP/1.1 403 Forbidden=20 The user does not have access to the=20 DingALing property.=20 =20 =20 =20 There has been an access violation error. =20 =20 =20 In this example, PROPFIND is executed on a non-collection resource=20 http://www.foo.bar/file. The propfind XML element specifies the=20 name of four properties whose values are being requested. In this=20 case only two properties were returned, since the principal issuing=20 the request did not have sufficient access rights to see the third=20 and fourth properties.=20 =20 =20 Expires Aug 2002 26=20 WebDAV =96 RFC2518 bis February 2002 = =20 8.1.2 Example - Using propname to Retrieve all Property Names=20 =20 >>Request=20 =20 PROPFIND /container/ HTTP/1.1=20 Host: www.foo.bar=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 =20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 http://www.foo.bar/container/=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 HTTP/1.1 200 OK=20 =20 =20 =20 http://www.foo.bar/container/front.html=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Expires Aug 2002 27=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 HTTP/1.1 200 OK=20 =20 =20 =20 =20 =20 In this example, PROPFIND is invoked on the collection resource=20 http://www.foo.bar/container/, with a propfind XML element=20 containing the propname XML element, meaning the name of all=20 properties should be returned. Since no Depth header is present, it=20 assumes its default value of "infinity", meaning the name of the=20 properties on the collection and all its progeny should be returned.=20 =20 Consistent with the previous example, resource=20 http://www.foo.bar/container/ has six properties defined on it,=20 http://www.foo.bar/boxschema/bigbox,=20 http://www.foo.bar/boxschema/author, DAV:creationdate,=20 DAV:displayname, DAV:resourcetype, and DAV:supportedlock. =20 =20 The resource http://www.foo.bar/container/index.html, a member of=20 the "container" collection, has nine properties defined on it,=20 http://www.foo.bar/boxschema/bigbox, DAV:creationdate,=20 DAV:displayname, DAV:getcontentlength, DAV:getcontenttype,=20 DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and=20 DAV:supportedlock.=20 =20 This example also demonstrates the use of XML namespace scoping, and=20 the default namespace. Since the "xmlns" attribute does not contain=20 an explicit "shorthand name" (prefix) letter, the namespace applies=20 by default to all enclosed elements. Hence, all elements which do=20 not explicitly state the namespace to which they belong are members=20 of the "DAV:" namespace schema.=20 =20 8.2 PROPPATCH=20 =20 The PROPPATCH method processes instructions specified in the request=20 body to set and/or remove properties defined on the resource=20 identified by the Request-URI.=20 =20 All DAV compliant resources MUST support the PROPPATCH method and=20 MUST process instructions that are specified using the=20 propertyupdate, set, and remove XML elements of the DAV schema. =20 Execution of the directives in this method is, of course, subject to=20 access control constraints. DAV compliant resources SHOULD support=20 the setting of arbitrary dead properties.=20 =20 The request message body of a PROPPATCH method MUST contain the=20 propertyupdate XML element. Instruction processing MUST occur in=20 the order instructions are received (i.e., from top to bottom).=20 =20 Expires Aug 2002 28=20 WebDAV =96 RFC2518 bis February 2002 = =20 Instructions MUST either all be executed or none executed. Thus if=20 any error occurs during processing all executed instructions MUST be=20 undone and a proper error result returned. Instruction processing=20 details can be found in the definition of the set and remove=20 instructions in section Error! Reference source not found..=20 =20 8.2.1 Status Codes for use with 207 (Multi-Status)=20 =20 The following are examples of response codes one would expect to be=20 used in a 207 (Multi-Status) response for this method. Note,=20 however, that unless explicitly prohibited any 2/3/4/5xx series=20 response code may be used in a 207 (Multi-Status) response.=20 =20 200 (OK) - The command succeeded. As there can be a mixture of sets=20 and removes in a body, a 201 (Created) seems inappropriate.=20 =20 403 (Forbidden) - The client, for reasons the server chooses not to=20 specify, cannot alter one of the properties.=20 =20 409 (Conflict) - The client has provided a value whose semantics are=20 not appropriate for the property. This includes trying to set read- only properties.=20 =20 423 (Locked) - The specified resource is locked and the client=20 either is not a lock owner or the lock type requires a lock token to=20 be submitted and the client did not submit it.=20 =20 507 (Insufficient Storage) - The server did not have sufficient=20 space to record the property.=20 =20 8.2.2 Example - PROPPATCH=20 =20 >>Request=20 =20 PROPPATCH /bar.html HTTP/1.1=20 Host: www.foo.com=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 =20 =20 Jim Whitehead=20 Roy Fielding=20 =20 =20 =20 Expires Aug 2002 29=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 =20 =20 =20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 http://www.foo.com/bar.html=20 =20 =20 HTTP/1.1 424 Failed Dependency=20 =20 =20 =20 HTTP/1.1 409 Conflict=20 =20 Copyright Owner can not be deleted or=20 altered.=20 =20 =20 =20 In this example, the client requests the server to set the value of=20 the "Authors" property in the "http://www.w3.com/standards/z39.50/"=20 namespace, and to remove the property "Copyright-Owner" in the=20 "http://www.w3.com/standards/z39.50/" namespace. Since the=20 Copyright-Owner property could not be removed, no property=20 modifications occur. The 424 (Failed Dependency) status code for=20 the Authors property indicates this action would have succeeded if=20 it were not for the conflict with removing the Copyright-Owner=20 property.=20 =20 8.3 MKCOL Method=20 =20 The MKCOL method is used to create a new collection. All DAV=20 compliant resources MUST support the MKCOL method.=20 =20 8.3.1 Request=20 =20 =20 Expires Aug 2002 30=20 WebDAV =96 RFC2518 bis February 2002 = =20 MKCOL creates a new collection resource at the location specified by=20 the Request-URI. If the resource identified by the Request-URI is=20 non-null then the MKCOL MUST fail. During MKCOL processing, a=20 server MUST make the Request-URI a member of its parent collection,=20 unless the Request-URI is "/". If no such ancestor exists, the=20 method MUST fail. When the MKCOL operation creates a new collection=20 resource, all ancestors MUST already exist, or the method MUST fail=20 with a 409 (Conflict) status code. For example, if a request to=20 create collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/=20 exists, the request must fail.=20 =20 When MKCOL is invoked without a request body, the newly created=20 collection SHOULD have no members.=20 =20 A MKCOL request message may contain a message body. The behavior of=20 a MKCOL request when the body is present is limited to creating=20 collections, members of a collection, bodies of members and=20 properties on the collections or members. If the server receives a=20 MKCOL request entity type it does not support or understand it MUST=20 respond with a 415 (Unsupported Media Type) status code. The exact=20 behavior of MKCOL for various request media types is undefined in=20 this document, and will be specified in separate documents.=20 =20 8.3.2 Status Codes=20 =20 Responses from a MKCOL request MUST NOT be cached as MKCOL has non- idempotent semantics.=20 =20 201 (Created) - The collection or structured resource was created in=20 its entirety.=20 =20 403 (Forbidden) - This indicates at least one of two conditions: 1)=20 the server does not allow the creation of collections at the given=20 location in its namespace, or 2) the parent collection of the=20 Request-URI exists but cannot accept members.=20 =20 405 (Method Not Allowed) - MKCOL can only be executed on a=20 deleted/non-existent resource.=20 =20 409 (Conflict) - A collection cannot be made at the Request-URI=20 until one or more intermediate collections have been created.=20 =20 415 (Unsupported Media Type)- The server does not support the=20 request type of the body.=20 =20 507 (Insufficient Storage) - The resource does not have sufficient=20 space to record the state of the resource after the execution of=20 this method.=20 =20 8.3.3 Example - MKCOL=20 =20 =20 Expires Aug 2002 31=20 WebDAV =96 RFC2518 bis February 2002 = =20 This example creates a collection called /webdisc/xfiles/ on the=20 server www.server.org.=20 =20 >>Request=20 =20 MKCOL /webdisc/xfiles/ HTTP/1.1=20 Host: www.server.org=20 =20 >>Response=20 =20 HTTP/1.1 201 Created=20 =20 =20 8.4 GET, HEAD for Collections=20 =20 The semantics of GET are unchanged when applied to a collection,=20 since GET is defined as, "retrieve whatever information (in the form=20 of an entity) is identified by the Request-URI" [RFC2068]. GET when=20 applied to a collection may return the contents of an "index.html"=20 resource, a human-readable view of the contents of the collection,=20 or something else altogether. Hence it is possible that the result=20 of a GET on a collection will bear no correlation to the membership=20 of the collection.=20 =20 Similarly, since the definition of HEAD is a GET without a response=20 message body, the semantics of HEAD are unmodified when applied to=20 collection resources.=20 =20 8.5 POST for Collections=20 =20 Since by definition the actual function performed by POST is=20 determined by the server and often depends on the particular=20 resource, the behavior of POST when applied to collections cannot be=20 meaningfully modified because it is largely undefined. Thus the=20 semantics of POST are unmodified when applied to a collection.=20 =20 8.6 DELETE=20 =20 8.6.1 DELETE for Non-Collection Resources=20 =20 If the DELETE method is issued to a non-collection resource whose=20 URIs are an internal member of one or more collections, then during=20 DELETE processing a server MUST remove any URI for the resource=20 identified by the Request-URI from collections which contain it as a=20 member.=20 =20 =20 Expires Aug 2002 32=20 WebDAV =96 RFC2518 bis February 2002 = =20 8.6.2 DELETE for Collections=20 =20 The DELETE method on a collection MUST act as if a "Depth: infinity"=20 header was used on it. A client MUST NOT submit a Depth header with=20 a DELETE on a collection with any value but infinity.=20 =20 DELETE instructs that the collection specified in the Request-URI=20 and all resources identified by its internal member URIs are to be=20 deleted.=20 =20 If any resource identified by a member URI cannot be deleted then=20 all of the member's ancestors MUST NOT be deleted, so as to maintain=20 namespace consistency.=20 =20 Any headers included with DELETE MUST be applied in processing every=20 resource to be deleted.=20 =20 When the DELETE method has completed processing it MUST result in a=20 consistent namespace.=20 =20 If an error occurs with a resource other than the resource=20 identified in the Request-URI then the response MUST be a 207=20 (Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the=20 207 (Multi-Status). They can be safely left out because the client=20 will know that the ancestors of a resource could not be deleted when=20 the client receives an error for the ancestor's progeny. =20 Additionally 204 (No Content) errors SHOULD NOT be returned in the=20 207 (Multi-Status). The reason for this prohibition is that 204 (No=20 Content) is the default success code.=20 =20 8.6.2.1 Example - DELETE=20 =20 >>Request=20 =20 DELETE /container/ HTTP/1.1=20 Host: www.foo.bar=20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 http://www.foo.bar/container/resource3=20 HTTP/1.1 423 Locked=20 =20 =20 =20 =20 Expires Aug 2002 33=20 WebDAV =96 RFC2518 bis February 2002 = =20 In this example the attempt to delete=20 http://www.foo.bar/container/resource3 failed because it is locked,=20 and no lock token was submitted with the request. Consequently, the=20 attempt to delete http://www.foo.bar/container/ also failed. Thus=20 the client knows that the attempt to delete=20 http://www.foo.bar/container/ must have also failed since the parent=20 can not be deleted unless its child has also been deleted. Even=20 though a Depth header has not been included, a depth of infinity is=20 assumed because the method is on a collection.=20 =20 8.7 PUT=20 =20 8.7.1 PUT for Non-Collection Resources=20 =20 A PUT performed on an existing resource replaces the GET response=20 entity of the resource. Properties defined on the resource may be=20 recomputed during PUT processing but are not otherwise affected. =20 For example, if a server recognizes the content type of the request=20 body, it may be able to automatically extract information that could=20 be profitably exposed as properties.=20 =20 A PUT that would result in the creation of a resource without an=20 appropriately scoped parent collection MUST fail with a 409=20 (Conflict).=20 =20 8.7.2 PUT for Collections=20 =20 As defined in the HTTP/1.1 specification [RFC2068], the "PUT method=20 requests that the enclosed entity be stored under the supplied=20 Request-URI." Since submission of an entity representing a=20 collection would implicitly encode creation and deletion of=20 resources, this specification intentionally does not define a=20 transmission format for creating a collection using PUT. Instead,=20 the MKCOL method is defined to create collections.=20 =20 When the PUT operation creates a new non-collection resource all=20 ancestors MUST already exist. If all ancestors do not exist, the=20 method MUST fail with a 409 (Conflict) status code. For example, if=20 resource /a/b/c/d.html is to be created and /a/b/c/ does not exist,=20 then the request must fail.=20 =20 8.8 COPY Method=20 =20 The COPY method creates a duplicate of the source resource,=20 identified by the Request-URI, in the destination resource,=20 identified by the URI in the Destination header. The Destination=20 header MUST be present. The exact behavior of the COPY method=20 depends on the type of the source resource.=20 =20 Expires Aug 2002 34=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 All WebDAV compliant resources MUST support the COPY method. =20 However, support for the COPY method does not guarantee the ability=20 to copy a resource. For example, separate programs may control=20 resources on the same server. As a result, it may not be possible=20 to copy a resource to a location that appears to be on the same=20 server.=20 =20 8.8.1 COPY for HTTP/1.1 resources=20 =20 When the source resource is not a collection the result of the COPY=20 method is the creation of a new resource at the destination whose=20 state and behavior match that of the source resource as closely as=20 possible. After a successful COPY invocation, all properties on the=20 source resource MUST be duplicated on the destination resource,=20 subject to modifying headers and XML elements, following the=20 definition for copying properties. Since the environment at the=20 destination may be different than at the source due to factors=20 outside the scope of control of the server, such as the absence of=20 resources required for correct operation, it may not be possible to=20 completely duplicate the behavior of the resource at the=20 destination. Subsequent alterations to the destination resource will=20 not modify the source resource. Subsequent alterations to the=20 source resource will not modify the destination resource.=20 =20 8.8.2 COPY for Properties=20 =20 Live properties described in this document SHOULD be duplicated as=20 identically behaving live properties at the destination resource. =20 If a property cannot be copied live, then its value MUST be=20 duplicated, octet-for-octet, in an identically named, dead property=20 on the destination resource.=20 =20 8.8.3 COPY for Collections=20 =20 The COPY method on a collection without a Depth header MUST act as=20 if a Depth header with value "infinity" was included. A client may=20 submit a Depth header on a COPY on a collection with a value of "0"=20 or "infinity". DAV compliant servers MUST support the "0" and=20 "infinity" Depth header behaviors.=20 =20 A COPY of depth infinity instructs that the collection resource=20 identified by the Request-URI is to be copied to the location=20 identified by the URI in the Destination header, and all its=20 internal member resources are to be copied to a location relative to=20 it, recursively through all levels of the collection hierarchy.=20 =20 =20 Expires Aug 2002 35=20 WebDAV =96 RFC2518 bis February 2002 = =20 A COPY of "Depth: 0" only instructs that the collection and its=20 properties but not resources identified by its internal member URIs,=20 are to be copied.=20 =20 Any headers included with a COPY MUST be applied in processing every=20 resource to be copied with the exception of the Destination header.=20 =20 The Destination header only specifies the destination URI for the=20 Request-URI. When applied to members of the collection identified by=20 the Request-URI the value of Destination is to be modified to=20 reflect the current location in the hierarchy. So, if the Request- URI is /a/ with Host header value http://fun.com/ and the=20 Destination is http://fun.com/b/ then when http://fun.com/a/c/d is=20 processed it must use a Destination of http://fun.com/b/c/d.=20 =20 When the COPY method has completed processing it MUST have created a=20 consistent namespace at the destination (see section 5.1 for the=20 definition of namespace consistency). However, if an error occurs=20 while copying an internal collection, the server MUST NOT copy any=20 resources identified by members of this collection (i.e., the server=20 must skip this subtree), as this would create an inconsistent=20 namespace. After detecting an error, the COPY operation SHOULD try=20 to finish as much of the original copy operation as possible (i.e.,=20 the server should still attempt to copy other subtrees and their=20 members, that are not descendents of an error-causing collection). =20 So, for example, if an infinite depth copy operation is performed on=20 collection /a/, which contains collections /a/b/ and /a/c/, and an=20 error occurs copying /a/b/, an attempt should still be made to copy=20 /a/c/. Similarly, after encountering an error copying a non- collection resource as part of an infinite depth copy, the server=20 SHOULD try to finish as much of the original copy operation as=20 possible.=20 =20 If an error in executing the COPY method occurs with a resource=20 other than the resource identified in the Request-URI then the=20 response MUST be a 207 (Multi-Status). =20 =20 The 424 (Failed Dependency) status code SHOULD NOT be returned in=20 the 207 (Multi-Status) response from a COPY method. These responses=20 can be safely omitted because the client will know that the progeny=20 of a resource could not be copied when the client receives an error=20 for the parent. Additionally 201 (Created)/204 (No Content) status=20 codes SHOULD NOT be returned as values in 207 (Multi-Status)=20 responses from COPY methods. They, too, can be safely omitted=20 because they are the default success codes.=20 =20 8.8.4 COPY and the Overwrite Header=20 =20 If a resource exists at the destination and the Overwrite header is=20 "T" then prior to performing the copy the server MUST perform a=20 DELETE with "Depth: infinity" on the destination resource. If the=20 Overwrite header is set to "F" then the operation will fail.=20 =20 Expires Aug 2002 36=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 8.8.5 Status Codes=20 =20 201 (Created) - The source resource was successfully copied. The=20 copy operation resulted in the creation of a new resource.=20 =20 204 (No Content) - The source resource was successfully copied to a=20 pre-existing destination resource.=20 =20 403 (Forbidden) =96 The source and destination URIs are the same.=20 =20 409 (Conflict) =96 A resource cannot be created at the destination=20 until one or more intermediate collections have been created.=20 =20 412 (Precondition Failed) =96 A precondition failed, e.g. the=20 Overwrite header is "F" and the state of the destination resource is=20 non-null.=20 =20 423 (Locked) - The destination resource was locked.=20 =20 502 (Bad Gateway) - This may occur when the destination is on=20 another server and the destination server refuses to accept the=20 resource.=20 =20 507 (Insufficient Storage) - The destination resource does not have=20 sufficient space to record the state of the resource after the=20 execution of this method.=20 =20 8.8.6 Example - COPY with Overwrite=20 =20 This example shows resource=20 http://www.ics.uci.edu/~fielding/index.html being copied to the=20 location http://www.ics.uci.edu/users/f/fielding/index.html. The=20 204 (No Content) status code indicates the existing resource at the=20 destination was overwritten.=20 =20 >>Request=20 =20 COPY /~fielding/index.html HTTP/1.1=20 Host: www.ics.uci.edu=20 Destination: http://www.ics.uci.edu/users/f/fielding/index.html=20 =20 >>Response=20 =20 HTTP/1.1 204 No Content=20 =20 8.8.7 Example - COPY with No Overwrite=20 =20 =20 Expires Aug 2002 37=20 WebDAV =96 RFC2518 bis February 2002 = =20 The following example shows the same copy operation being performed,=20 but with the Overwrite header set to "F." A response of 412=20 (Precondition Failed) is returned because the destination resource=20 has a non-null state.=20 =20 >>Request=20 =20 COPY /~fielding/index.html HTTP/1.1=20 Host: www.ics.uci.edu=20 Destination: http://www.ics.uci.edu/users/f/fielding/index.html=20 Overwrite: F=20 =20 >>Response=20 =20 HTTP/1.1 412 Precondition Failed=20 =20 8.8.8 Example - COPY of a Collection=20 =20 >>Request=20 =20 COPY /container/ HTTP/1.1=20 Host: www.foo.bar=20 Destination: http://www.foo.bar/othercontainer/=20 Depth: infinity=20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 =20 http://www.foo.bar/othercontainer/R2/=20 HTTP/1.1 423 Locked=20 =20 =20 =20 The Depth header is unnecessary as the default behavior of COPY on a=20 collection is to act as if a "Depth: infinity" header had been=20 submitted. In this example most of the resources, along with the=20 collection, were copied successfully. However the collection R2=20 failed because the destination R2 is locked. Because there was an=20 error copying R2, none of R2's members were copied. However no=20 errors were listed for those members due to the error minimization=20 rules given in section 8.8.3.=20 =20 =20 Expires Aug 2002 38=20 WebDAV =96 RFC2518 bis February 2002 = =20 8.9 MOVE Method=20 =20 The MOVE operation on a non-collection resource is the logical=20 equivalent of a copy (COPY), followed by consistency maintenance=20 processing, followed by a delete of the source, where all three=20 actions are performed atomically. The consistency maintenance step=20 allows the server to perform updates caused by the move, such as=20 updating all URIs other than the Request-URI which identify the=20 source resource, to point to the new destination resource. =20 Consequently, the Destination header MUST be present on all MOVE=20 methods and MUST follow all COPY requirements for the COPY part of=20 the MOVE method. All DAV compliant resources MUST support the MOVE=20 method. However, support for the MOVE method does not guarantee the=20 ability to move a resource to a particular destination. =20 =20 For example, separate programs may actually control different sets=20 of resources on the same server. Therefore, it may not be possible=20 to move a resource within a namespace that appears to belong to the=20 same server.=20 =20 If a resource exists at the destination, the destination resource=20 will be DELETEd as a side-effect of the MOVE operation, subject to=20 the restrictions of the Overwrite header.=20 =20 8.9.1 MOVE for Properties=20 =20 The behavior of properties on a MOVE MUST be the same as specified=20 in section 8.8.2.=20 =20 8.9.2 MOVE for Collections=20 =20 A MOVE with "Depth: infinity" instructs that the collection=20 identified by the Request-URI be moved to the URI specified in the=20 Destination header, and all resources identified by its internal=20 member URIs are to be moved to locations relative to it, recursively=20 through all levels of the collection hierarchy.=20 =20 The MOVE method on a collection MUST act as if a "Depth: infinity"=20 header was used on it. A client MUST NOT submit a Depth header on a=20 MOVE on a collection with any value but "infinity".=20 =20 Any headers included with MOVE MUST be applied in processing every=20 resource to be moved with the exception of the Destination header.=20 =20 The behavior of the Destination header is the same as given for COPY=20 on collections. =20 =20 When the MOVE method has completed processing it MUST have created a=20 consistent namespace at both the source and destination (see section=20 5.1 for the definition of namespace consistency). However, if an=20 =20 Expires Aug 2002 39=20 WebDAV =96 RFC2518 bis February 2002 = =20 error occurs while moving an internal collection, the server MUST=20 NOT move any resources identified by members of the failed=20 collection (i.e., the server must skip the error-causing subtree),=20 as this would create an inconsistent namespace. In this case, after=20 detecting the error, the move operation SHOULD try to finish as much=20 of the original move as possible (i.e., the server should still=20 attempt to move other subtrees and the resources identified by their=20 members, that are not descendents of an error-causing collection). =20 So, for example, if an infinite depth move is performed on=20 collection /a/, which contains collections /a/b/ and /a/c/, and an=20 error occurs moving /a/b/, an attempt should still be made to try=20 moving /a/c/. Similarly, after encountering an error moving a non- collection resource as part of an infinite depth move, the server=20 SHOULD try to finish as much of the original move operation as=20 possible.=20 =20 If an error occurs with a resource other than the resource=20 identified in the Request-URI then the response MUST be a 207=20 (Multi-Status).=20 =20 The 424 (Failed Dependency) status code SHOULD NOT be returned in=20 the 207 (Multi-Status) response from a MOVE method. These errors=20 can be safely omitted because the client will know that the progeny=20 of a resource could not be moved when the client receives an error=20 for the parent. Additionally 201 (Created)/204 (No Content)=20 responses SHOULD NOT be returned as values in 207 (Multi-Status)=20 responses from a MOVE. These responses can be safely omitted=20 because they are the default success codes.=20 =20 8.9.3 MOVE and the Overwrite Header=20 =20 If a resource exists at the destination and the Overwrite header is=20 "T" then prior to performing the move the server MUST perform a=20 DELETE with "Depth: infinity" on the destination resource. If the=20 Overwrite header is set to "F" then the operation will fail.=20 =20 8.9.4 Status Codes=20 =20 201 (Created) - The source resource was successfully moved, and a=20 new resource was created at the destination.=20 =20 204 (No Content) - The source resource was successfully moved to a=20 pre-existing destination resource.=20 =20 403 (Forbidden) =96 The source and destination URIs are the same.=20 =20 409 (Conflict) =96 A resource cannot be created at the destination=20 until one or more intermediate collections have been created.=20 =20 412 (Precondition Failed) =96 A condition failed, e.g. the Overwrite=20 header is "F" and the state of the destination resource is non-null.=20 =20 Expires Aug 2002 40=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 423 (Locked) - The source or the destination resource was locked.=20 =20 502 (Bad Gateway) - This may occur when the destination is on=20 another server and the destination server refuses to accept the=20 resource.=20 =20 8.9.5 Example - MOVE of a Non-Collection=20 =20 This example shows resource=20 http://www.ics.uci.edu/~fielding/index.html being moved to the=20 location http://www.ics.uci.edu/users/f/fielding/index.html. The=20 contents of the destination resource would have been overwritten if=20 the destination resource had been non-null. In this case, since=20 there was nothing at the destination resource, the response code is=20 201 (Created).=20 =20 >>Request=20 =20 MOVE /~fielding/index.html HTTP/1.1=20 Host: www.ics.uci.edu=20 Destination: http://www.ics.uci.edu/users/f/fielding/index.html=20 =20 >>Response=20 =20 HTTP/1.1 201 Created=20 Location: http://www.ics.uci.edu/users/f/fielding/index.html=20 =20 =20 8.9.6 Example - MOVE of a Collection=20 =20 >>Request=20 =20 MOVE /container/ HTTP/1.1=20 Host: www.foo.bar=20 Destination: http://www.foo.bar/othercontainer/=20 Overwrite: F=20 If: ()=20 ()=20 =20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 Expires Aug 2002 41=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 http://www.foo.bar/othercontainer/C2/=20 HTTP/1.1 423 Locked=20 =20 =20 =20 In this example the client has submitted a number of lock tokens=20 with the request. A lock token will need to be submitted for every=20 resource, both source and destination, anywhere in the scope of the=20 method, that is locked. In this case the proper lock token was not=20 submitted for the destination http://www.foo.bar/othercontainer/C2/.=20 This means that the resource /container/C2/ could not be moved. =20 Because there was an error copying /container/C2/, none of=20 /container/C2's members were copied. However no errors were listed=20 for those members due to the error minimization rules given in=20 section 8.8.3. User agent authentication has previously occurred=20 via a mechanism outside the scope of the HTTP protocol, in an=20 underlying transport layer.=20 =20 8.10 LOCK Method=20 =20 The following sections describe the LOCK method, which is used to=20 take out a lock of any access type. These sections on the LOCK=20 method describe only those semantics that are specific to the LOCK=20 method and are independent of the access type of the lock being=20 requested.=20 =20 Any resource which supports the LOCK method MUST, at minimum,=20 support the XML request and response formats defined herein.=20 =20 8.10.1 Operation=20 =20 A LOCK method invocation creates the lock specified by the lockinfo=20 XML element on the Request-URI. Lock method requests SHOULD have a=20 XML request body which contains an owner XML element for this lock=20 request, unless this is a refresh request. The server MUST preserve=20 the information provided by the client in the owner field when the=20 lock information is requested. The LOCK request may have a Timeout=20 header.=20 =20 Clients MUST assume that locks may arbitrarily disappear at any=20 time, regardless of the value given in the Timeout header. The=20 Timeout header only indicates the behavior of the server if=20 "extraordinary" circumstances do not occur. For example, a=20 sufficiently privileged user may remove a lock at any time or the=20 system may crash in such a way that it loses the record of the=20 lock's existence. The response MUST contain the value of the=20 lockdiscovery property in a prop XML element.=20 =20 =20 Expires Aug 2002 42=20 WebDAV =96 RFC2518 bis February 2002 = =20 In order to indicate the lock token associated with a newly created=20 lock, a Lock-Token response header MUST be included in the response=20 for every successful LOCK request for a new lock. Note that the=20 Lock-Token header would not be returned in the response for a=20 successful refresh LOCK request because a new lock was not created.=20 =20 8.10.2 The Effect of Locks on Properties and Collections=20 =20 The scope of a lock is the entire state of the resource, including=20 its body and associated properties. As a result, a lock on a=20 resource MUST also lock the resource's properties.=20 =20 For collections, a lock also affects the ability to add or remove=20 members. The nature of the effect depends upon the type of access=20 control involved.=20 =20 8.10.3 Locking Replicated Resources=20 =20 A resource may be made available through more than one URI. However=20 locks apply to resources, not URIs. Therefore a LOCK request on a=20 resource MUST NOT succeed if can not be honored by all the URIs=20 through which the resource is addressable.=20 =20 8.10.4 Depth and Locking=20 =20 The Depth header may be used with the LOCK method. Values other=20 than 0 or infinity MUST NOT be used with the Depth header on a LOCK=20 method. All resources that support the LOCK method MUST support the=20 Depth header.=20 =20 A Depth header of value 0 means to just lock the resource specified=20 by the Request-URI.=20 =20 If the Depth header is set to infinity then the resource specified=20 in the Request-URI along with all its internal members, all the way=20 down the hierarchy, are to be locked. A successful result MUST=20 return a single lock token which represents all the resources that=20 have been locked. If an UNLOCK is successfully executed on this=20 token, all associated resources are unlocked. If the lock cannot be=20 granted to all resources, a 409 (Conflict) status code MUST be=20 returned with a response entity body containing a multistatus XML=20 element describing which resource(s) prevented the lock from being=20 granted. Hence, partial success is not an option. Either the=20 entire hierarchy is locked or no resources are locked.=20 =20 If no Depth header is submitted on a LOCK request then the request=20 MUST act as if a "Depth:infinity" had been submitted.=20 =20 =20 Expires Aug 2002 43=20 WebDAV =96 RFC2518 bis February 2002 = =20 8.10.5 Interaction with other Methods=20 =20 The interaction of a LOCK with various methods is dependent upon the=20 lock type. However, independent of lock type, a successful DELETE=20 of a resource MUST cause all of its locks to be removed.=20 =20 8.10.6 Lock Compatibility Table=20 =20 The table below describes the behavior that occurs when a lock=20 request is made on a resource.=20 =20 CURRENT LOCK STATE/ SHARED EXCLUSIVE=20 LOCK REQUEST LOCK LOCK=20 None True True=20 Shared Lock True False=20 Exclusive Lock False False*=20 =20 =20 Legend: True =3D lock may be granted. False =3D lock MUST NOT be=20 granted. *=3DIt is illegal for a principal to request the same lock=20 twice.=20 =20 The current lock state of a resource is given in the leftmost=20 column, and lock requests are listed in the first row. The=20 intersection of a row and column gives the result of a lock request. = For example, if a shared lock is held on a resource, and an=20 exclusive lock is requested, the table entry is "false", indicating=20 the lock must not be granted.=20 =20 8.10.7 Status Codes=20 =20 200 (OK) - The lock request succeeded and the value of the=20 lockdiscovery property is included in the body.=20 =20 409 (Conflict) =96 A resource cannot be created at the destination=20 until one or more intermediate collections have been created.=20 =20 412 (Precondition Failed) - The included lock token was not=20 enforceable on this resource or the server could not satisfy the=20 request in the lockinfo XML element.=20 =20 423 (Locked) - The resource is locked, so the method has been=20 rejected. =20 8.10.8 Example - Simple Lock Request=20 =20 >>Request=20 =20 LOCK /workspace/webdav/proposal.doc HTTP/1.1=20 =20 Expires Aug 2002 44=20 WebDAV =96 RFC2518 bis February 2002 = =20 Host: webdav.sb.aol.com=20 Timeout: Infinite, Second-4100000000=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 Authorization: Digest username=3D"ejw",=20 realm=3D"ejw@webdav.sb.aol.com", nonce=3D"...",=20 uri=3D"/workspace/webdav/proposal.doc",=20 response=3D"...", opaque=3D"..."=20 =20 =20 =20 =20 =20 =20 http://www.ics.uci.edu/~ejw/contact.html=20 =20 =20 =20 >>Response=20 =20 HTTP/1.1 200 OK=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 =20 =20 =20 infinity=20 =20 =20 http://www.ics.uci.edu/~ejw/contact.html=20 =20 =20 Second-604800=20 =20 =20 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4=20 =20 =20 =20 =20 =20 =20 This example shows the successful creation of an exclusive write=20 lock on resource=20 =20 Expires Aug 2002 45=20 WebDAV =96 RFC2518 bis February 2002 = =20 http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The=20 resource http://www.ics.uci.edu/~ejw/contact.html contains contact=20 information for the owner of the lock. The server has an activity- based timeout policy in place on this resource, which causes the=20 lock to automatically be removed after 1 week (604800 seconds). =20 Note that the nonce, response, and opaque fields have not been=20 calculated in the Authorization request header.=20 =20 8.10.9 Example - Refreshing a Write Lock=20 =20 >>Request=20 =20 LOCK /workspace/webdav/proposal.doc HTTP/1.1=20 Host: webdav.sb.aol.com=20 Timeout: Infinite, Second-4100000000=20 If: ()=20 Authorization: Digest username=3D"ejw",=20 realm=3D"ejw@webdav.sb.aol.com", nonce=3D"...",=20 uri=3D"/workspace/webdav/proposal.doc",=20 response=3D"...", opaque=3D"..."=20 =20 >>Response=20 =20 HTTP/1.1 200 OK=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 =20 =20 =20 infinity=20 =20 =20 http://www.ics.uci.edu/~ejw/contact.html=20 =20 =20 Second-604800=20 =20 =20 opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4=20 =20 =20 =20 =20 =20 =20 Expires Aug 2002 46=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 This request would refresh the lock, resetting any time outs. =20 Notice that the client asked for an infinite time out but the server=20 choose to ignore the request. In this example, the nonce, response,=20 and opaque fields have not been calculated in the Authorization=20 request header.=20 =20 8.10.10 Example - Multi-Resource Lock Request=20 =20 >>Request=20 =20 LOCK /webdav/ HTTP/1.1=20 Host: webdav.sb.aol.com=20 Timeout: Infinite, Second-4100000000=20 Depth: infinity=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 Authorization: Digest username=3D"ejw",=20 realm=3D"ejw@webdav.sb.aol.com", nonce=3D"...",=20 uri=3D"/workspace/webdav/proposal.doc",=20 response=3D"...", opaque=3D"..."=20 =20 =20 =20 =20 =20 =20 http://www.ics.uci.edu/~ejw/contact.html=20 =20 =20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 http://webdav.sb.aol.com/webdav/secret=20 HTTP/1.1 403 Forbidden=20 =20 =20 http://webdav.sb.aol.com/webdav/=20 =20 =20 HTTP/1.1 424 Failed Dependency=20 =20 Expires Aug 2002 47=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 =20 =20 This example shows a request for an exclusive write lock on a=20 collection and all its children. In this request, the client has=20 specified that it desires an infinite length lock, if available,=20 otherwise a timeout of 4.1 billion seconds, if available. The=20 request entity body contains the contact information for the=20 principal taking out the lock, in this case a web page URL.=20 =20 The error is a 403 (Forbidden) response on the resource=20 http://webdav.sb.aol.com/webdav/secret. Because this resource could=20 not be locked, none of the resources were locked. Note also that=20 the lockdiscovery property for the Request-URI has been included as=20 required. In this example the lockdiscovery property is empty which=20 means that there are no outstanding locks on the resource.=20 =20 In this example, the nonce, response, and opaque fields have not=20 been calculated in the Authorization request header.=20 =20 8.11 UNLOCK Method=20 =20 The UNLOCK method removes the lock identified by the lock token in=20 the Lock-Token request header from the Request-URI, and all other=20 resources included in the lock. If all resources which have been=20 locked under the submitted lock token can not be unlocked then the=20 UNLOCK request MUST fail.=20 =20 Any DAV compliant resource which supports the LOCK method MUST=20 support the UNLOCK method.=20 =20 8.11.1 Example - UNLOCK=20 =20 >>Request=20 =20 UNLOCK /workspace/webdav/info.doc HTTP/1.1=20 Host: webdav.sb.aol.com=20 Lock-Token: =20 Authorization: Digest username=3D"ejw",=20 realm=3D"ejw@webdav.sb.aol.com", nonce=3D"...",=20 uri=3D"/workspace/webdav/proposal.doc",=20 response=3D"...", opaque=3D"..."=20 =20 >>Response=20 =20 HTTP/1.1 204 No Content=20 =20 =20 =20 Expires Aug 2002 48=20 WebDAV =96 RFC2518 bis February 2002 = =20 In this example, the lock identified by the lock token=20 "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is=20 successfully removed from the resource=20 http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock=20 included more than just one resource, the lock is removed from all=20 resources included in the lock. The 204 (No Content) status code is=20 used instead of 200 (OK) because there is no response entity body.=20 =20 In this example, the nonce, response, and opaque fields have not=20 been calculated in the Authorization request header.=20 =20 =20 9 HTTP Headers for Distributed Authoring=20 =20 9.1 DAV Header=20 =20 DAV =3D "DAV" ":" "1" ["," "2"] ["," 1#extend]=20 =20 This header indicates that the resource supports the DAV schema and=20 protocol as specified. All DAV compliant resources MUST return the=20 DAV header on all OPTIONS responses.=20 =20 The value is a list of all compliance classes that the resource=20 supports. Note that above a comma has already been added to the 2.=20 This is because a resource can not be level 2 compliant unless it is=20 also level 1 compliant. Please refer to section Error! Reference=20 source not found. for more details. In general, however, support for=20 one compliance class does not entail support for any other. =20 =20 9.2 Depth Header=20 =20 Depth =3D "Depth" ":" ("0" | "1" | "infinity")=20 =20 The Depth header is used with methods executed on resources which=20 could potentially have internal members to indicate whether the=20 method is to be applied only to the resource ("Depth: 0"), to the=20 resource and its immediate children, ("Depth: 1"), or the resource=20 and all its progeny ("Depth: infinity").=20 =20 The Depth header is only supported if a method's definition=20 explicitly provides for such support.=20 =20 The following rules are the default behavior for any method that=20 supports the Depth header. A method may override these defaults by=20 defining different behavior in its definition.=20 =20 Methods which support the Depth header may choose not to support all=20 of the header's values and may define, on a case by case basis, the=20 behavior of the method if a Depth header is not present. For=20 =20 Expires Aug 2002 49=20 WebDAV =96 RFC2518 bis February 2002 = =20 example, the MOVE method only supports "Depth: infinity" and if a=20 Depth header is not present will act as if a "Depth: infinity"=20 header had been applied.=20 =20 Clients MUST NOT rely upon methods executing on members of their=20 hierarchies in any particular order or on the execution being atomic=20 unless the particular method explicitly provides such guarantees.=20 =20 Upon execution, a method with a Depth header will perform as much of=20 its assigned task as possible and then return a response specifying=20 what it was able to accomplish and what it failed to do.=20 =20 So, for example, an attempt to COPY a hierarchy may result in some=20 of the members being copied and some not.=20 =20 Any headers on a method that has a defined interaction with the=20 Depth header MUST be applied to all resources in the scope of the=20 method except where alternative behavior is explicitly defined. For=20 example, an If-Match header will have its value applied against=20 every resource in the method's scope and will cause the method to=20 fail if the header fails to match.=20 =20 If a resource, source or destination, within the scope of the method=20 with a Depth header is locked in such a way as to prevent the=20 successful execution of the method, then the lock token for that=20 resource MUST be submitted with the request in the If request=20 header.=20 =20 The Depth header only specifies the behavior of the method with=20 regards to internal children. If a resource does not have internal=20 children then the Depth header MUST be ignored.=20 =20 Please note, however, that it is always an error to submit a value=20 for the Depth header that is not allowed by the method's definition. = Thus submitting a "Depth: 1" on a COPY, even if the resource does=20 not have internal members, will result in a 400 (Bad Request). The=20 method should fail not because the resource doesn't have internal=20 members, but because of the illegal value in the header.=20 =20 9.3 Destination Header=20 =20 Destination =3D "Destination" ":" absoluteURI=20 =20 The Destination header specifies the URI which identifies a=20 destination resource for methods such as COPY and MOVE, which take=20 two URIs as parameters. Note that the absoluteURI production is=20 defined in [RFC2396].=20 =20 9.4 If Header=20 =20 =20 Expires Aug 2002 50=20 WebDAV =96 RFC2518 bis February 2002 = =20 If =3D "If" ":" ( 1*No-tag-list | 1*Tagged-list)=20 No-tag-list =3D List=20 Tagged-list =3D Resource 1*List=20 Resource =3D Coded-URL=20 List =3D "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"=20 State-token =3D Coded-URL=20 Coded-URL =3D "<" absoluteURI ">"=20 =20 The If header is intended to have similar functionality to the If- Match header defined in section 14.25 of [RFC2068]. However the If=20 header is intended for use with any URI which represents state=20 information, referred to as a state token, about a resource as well=20 as ETags. A typical example of a state token is a lock token, and=20 lock tokens are the only state tokens defined in this specification.=20 =20 All DAV compliant resources MUST honor the If header.=20 =20 The If header's purpose is to describe a series of state lists. If=20 the state of the resource to which the header is applied does not=20 match any of the specified state lists then the request MUST fail=20 with a 412 (Precondition Failed). If one of the described state=20 lists matches the state of the resource then the request may=20 succeed.=20 =20 Note that the absoluteURI production is defined in [RFC2396].=20 =20 9.4.1 No-tag-list Production=20 =20 The No-tag-list production describes a series of state tokens and=20 ETags. If multiple No-tag-list productions are used then one only=20 needs to match the state of the resource for the method to be=20 allowed to continue.=20 =20 If a method, due to the presence of a Depth or Destination header,=20 is applied to multiple resources then the No-tag-list production=20 MUST be applied to each resource the method is applied to.=20 =20 9.4.1.1 Example - No-tag-list If Header=20 =20 If: ( ["I am an ETag"]) (["I am=20 another ETag"])=20 =20 The previous header would require that any resources within the=20 scope of the method must either be locked with the specified lock=20 token and in the state identified by the "I am an ETag" ETag or in=20 the state identified by the second ETag "I am another ETag". To put=20 the matter more plainly one can think of the previous If header as=20 being in the form (or (and ["I am an=20 ETag"]) (and ["I am another ETag"])).=20 =20 =20 Expires Aug 2002 51=20 WebDAV =96 RFC2518 bis February 2002 = =20 9.4.2 Tagged-list Production=20 =20 The tagged-list production scopes a list production. That is, it=20 specifies that the lists following the resource specification only=20 apply to the specified resource. The scope of the resource=20 production begins with the list production immediately following the=20 resource production and ends with the next resource production, if=20 any.=20 =20 When the If header is applied to a particular resource, the Tagged- list productions MUST be searched to determine if any of the listed=20 resources match the operand resource(s) for the current method. If=20 none of the resource productions match the current resource then the=20 header MUST be ignored. If one of the resource productions does=20 match the name of the resource under consideration then the list=20 productions following the resource production MUST be applied to the=20 resource in the manner specified in the previous section.=20 =20 The same URI MUST NOT appear more than once in a resource production=20 in an If header.=20 =20 9.4.2.1 Example - Tagged List If header=20 =20 COPY /resource1 HTTP/1.1=20 Host: www.foo.bar=20 Destination: http://www.foo.bar/resource2=20 If: (=20 [W/"A weak ETag"]) (["strong ETag"])=20 (["another strong ETag"])=20 =20 In this example http://www.foo.bar/resource1 is being copied to=20 http://www.foo.bar/resource2. When the method is first applied to=20 http://www.foo.bar/resource1, resource1 must be in the state=20 specified by "( [W/"A weak ETag"])=20 (["strong ETag"])", that is, it either must be locked with a lock=20 token of "locktoken:a-write-lock-token" and have a weak entity tag=20 W/"A weak ETag" or it must have a strong entity tag "strong ETag".=20 =20 That is the only success condition since the resource=20 http://www.bar.bar/random never has the method applied to it (the=20 only other resource listed in the If header) and=20 http://www.foo.bar/resource2 is not listed in the If header.=20 =20 9.4.3 not Production=20 =20 Every state token or ETag is either current, and hence describes the=20 state of a resource, or is not current, and does not describe the=20 state of a resource. The boolean operation of matching a state token=20 or ETag to the current state of a resource thus resolves to a true=20 or false value. The not production is used to reverse that value. =20 =20 Expires Aug 2002 52=20 WebDAV =96 RFC2518 bis February 2002 = =20 The scope of the not production is the state-token or entity-tag=20 immediately following it.=20 =20 If: (Not )=20 =20 When submitted with a request, this If header requires that all=20 operand resources must not be locked with locktoken:write1 and must=20 be locked with locktoken:write2.=20 =20 9.4.4 Matching Function=20 =20 When performing If header processing, the definition of a matching=20 state token or entity tag is as follows.=20 =20 Matching entity tag: Where the entity tag matches an entity tag=20 associated with that resource.=20 =20 Matching state token: Where there is an exact match between the=20 state token in the If header and any state token on the resource.=20 =20 9.4.5 If Header and Non-DAV Compliant Proxies=20 =20 Non-DAV compliant proxies will not honor the If header, since they=20 will not understand the If header, and HTTP requires non-understood=20 headers to be ignored. When communicating with HTTP/1.1 proxies,=20 the "Cache-Control: no-cache" request header MUST be used so as to=20 prevent the proxy from improperly trying to service the request from=20 its cache. When dealing with HTTP/1.0 proxies the "Pragma: no- cache" request header MUST be used for the same reason.=20 =20 9.5 Lock-Token Header=20 =20 Lock-Token =3D "Lock-Token" ":" Coded-URL=20 =20 The Lock-Token request header is used with the UNLOCK method to=20 identify the lock to be removed. The lock token in the Lock-Token=20 request header MUST identify a lock that contains the resource=20 identified by Request-URI as a member.=20 =20 The Lock-Token response header is used with the LOCK method to=20 indicate the lock token created as a result of a successful LOCK=20 request to create a new lock.=20 =20 9.6 Overwrite Header=20 =20 Overwrite =3D "Overwrite" ":" ("T" | "F")=20 =20 =20 Expires Aug 2002 53=20 WebDAV =96 RFC2518 bis February 2002 = =20 The Overwrite header specifies whether the server should overwrite=20 the state of a non-null destination resource during a COPY or MOVE. =20 A value of "F" states that the server must not perform the COPY or=20 MOVE operation if the state of the destination resource is non-null.=20 If the overwrite header is not included in a COPY or MOVE request=20 then the resource MUST treat the request as if it has an overwrite=20 header of value "T". While the Overwrite header appears to duplicate=20 the functionality of the If-Match: * header of HTTP/1.1, If-Match=20 applies only to the Request-URI, and not to the Destination of a=20 COPY or MOVE.=20 =20 If a COPY or MOVE is not performed due to the value of the Overwrite=20 header, the method MUST fail with a 412 (Precondition Failed) status=20 code.=20 =20 All DAV compliant resources MUST support the Overwrite header.=20 =20 9.7 Status-URI Response Header=20 =20 The Status-URI response header may be used with the 102 (Processing)=20 status code to inform the client as to the status of a method.=20 =20 Status-URI =3D "Status-URI" ":" *(Status-Code Coded-URL) ; = Status-Code=20 is defined in 6.1.1 of [RFC2068]=20 =20 The URIs listed in the header are source resources which have been=20 affected by the outstanding method. The status code indicates the=20 resolution of the method on the identified resource. So, for=20 example, if a MOVE method on a collection is outstanding and a 102=20 (Processing) response with a Status-URI response header is returned,=20 the included URIs will indicate resources that have had move=20 attempted on them and what the result was.=20 =20 9.8 Timeout Request Header=20 =20 TimeOut =3D "Timeout" ":" 1#TimeType=20 TimeType =3D ("Second-" DAVTimeOutVal | "Infinite" | Other)=20 DAVTimeOutVal =3D 1*digit=20 Other =3D "Extend" field-value ; See section 4.2 of [RFC2068]=20 =20 Clients may include Timeout headers in their LOCK requests. =20 However, the server is not required to honor or even consider these=20 requests. Clients MUST NOT submit a Timeout request header with any=20 method other than a LOCK method.=20 =20 A Timeout request header MUST contain at least one TimeType and may=20 contain multiple TimeType entries. The purpose of listing multiple=20 TimeType entries is to indicate multiple different values and value=20 types that are acceptable to the client. The client lists the=20 TimeType entries in order of preference.=20 =20 Expires Aug 2002 54=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 Timeout response values MUST use a Second value, Infinite, or a=20 TimeType the client has indicated familiarity with. The server may=20 assume a client is familiar with any TimeType submitted in a Timeout=20 header.=20 =20 The "Second" TimeType specifies the number of seconds that will=20 elapse between granting of the lock at the server, and the automatic=20 removal of the lock. The timeout value for TimeType "Second" MUST=20 NOT be greater than 2^32-1.=20 =20 The timeout counter SHOULD NOT be restarted any time an owner of the=20 lock sends a method to any member of the lock, including unsupported=20 methods, or methods which are unsuccessful. However the lock MUST=20 be refreshed if a refresh LOCK method is successfully received.=20 =20 If the timeout expires then the lock may be lost. Specifically, if=20 the server wishes to harvest the lock upon time-out, the server=20 SHOULD act as if an UNLOCK method was executed by the server on the=20 resource using the lock token of the timed-out lock, performed with=20 its override authority. Thus logs should be updated with the=20 disposition of the lock, notifications should be sent, etc., just as=20 they would be for an UNLOCK request.=20 =20 Servers are advised to pay close attention to the values submitted=20 by clients, as they will be indicative of the type of activity the=20 client intends to perform. For example, an applet running in a=20 browser may need to lock a resource, but because of the instability=20 of the environment within which the applet is running, the applet=20 may be turned off without warning. As a result, the applet is=20 likely to ask for a relatively small timeout value so that if the=20 applet dies, the lock can be quickly harvested. However, a document=20 management system is likely to ask for an extremely long timeout=20 because its user may be planning on going off-line.=20 =20 A client MUST NOT assume that just because the time-out has expired=20 the lock has been lost.=20 =20 =20 10 Status Code Extensions to HTTP/1.1=20 =20 The following status codes are added to those defined in HTTP/1.1=20 [RFC2068].=20 =20 10.1 102 Processing=20 =20 The 102 (Processing) status code is an interim response used to=20 inform the client that the server has accepted the complete request,=20 but has not yet completed it. This status code SHOULD only be sent=20 when the server has a reasonable expectation that the request will=20 take significant time to complete. As guidance, if a method is=20 =20 Expires Aug 2002 55=20 WebDAV =96 RFC2518 bis February 2002 = =20 taking longer than 20 seconds (a reasonable, but arbitrary value) to=20 process the server SHOULD return a 102 (Processing) response. The=20 server MUST send a final response after the request has been=20 completed.=20 =20 Methods can potentially take a long period of time to process,=20 especially methods that support the Depth header. In such cases the=20 client may time-out the connection while waiting for a response. To=20 prevent this the server may return a 102 (Processing) status code to=20 indicate to the client that the server is still processing the=20 method.=20 =20 10.2 207 Multi-Status=20 =20 The 207 (Multi-Status) status code provides status for multiple=20 independent operations (see section Error! Reference source not=20 found. for more information).=20 =20 10.3 422 Unprocessable Entity=20 =20 The 422 (Unprocessable Entity) status code means the server=20 understands the content type of the request entity (hence a=20 415(Unsupported Media Type) status code is inappropriate), and the=20 syntax of the request entity is correct (thus a 400 (Bad Request)=20 status code is inappropriate) but was unable to process the=20 contained instructions. For example, this error condition may occur=20 if an XML request body contains well-formed (i.e., syntactically=20 correct), but semantically erroneous XML instructions.=20 =20 10.4 423 Locked=20 =20 The 423 (Locked) status code means the source or destination=20 resource of a method is locked.=20 =20 10.5 424 Failed Dependency=20 =20 The 424 (Failed Dependency) status code means that the method could=20 not be performed on the resource because the requested action=20 depended on another action and that action failed. For example, if=20 a command in a PROPPATCH method fails then, at minimum, the rest of=20 the commands will also fail with 424 (Failed Dependency).=20 =20 10.6 507 Insufficient Storage=20 =20 The 507 (Insufficient Storage) status code means the method could=20 not be performed on the resource because the server is unable to=20 store the representation needed to successfully complete the=20 =20 Expires Aug 2002 56=20 WebDAV =96 RFC2518 bis February 2002 = =20 request. This condition is considered to be temporary. If the=20 request which received this status code was the result of a user=20 action, the request MUST NOT be repeated until it is requested by a=20 separate user action.=20 =20 =20 11 Multi-Status Response=20 =20 The default 207 (Multi-Status) response body is a text/xml or=20 application/xml HTTP entity that contains a single XML element=20 called multistatus, which contains a set of XML elements called=20 response which contain 200, 300, 400, and 500 series status codes=20 generated during the method invocation. 100 series status codes=20 SHOULD NOT be recorded in a response XML element.=20 =20 =20 12 XML Element Definitions=20 =20 In the section below, the final line of each section gives the=20 element type declaration using the format defined in [REC-XML]. The=20 "Value" field, where present, specifies further restrictions on the=20 allowable contents of the XML element using BNF (i.e., to further=20 restrict the values of a PCDATA element).=20 =20 12.1 activelock XML Element=20 =20 Name: activelock=20 Namespace: DAV:=20 Purpose: Describes a lock on a resource.=20 =20 =20 =20 12.1.1 depth XML Element=20 =20 Name: depth=20 Namespace: DAV:=20 Purpose: The value of the Depth header.=20 Value: "0" | "1" | "infinity"=20 =20 =20 =20 12.1.2 locktoken XML Element=20 =20 Name: locktoken=20 =20 Expires Aug 2002 57=20 WebDAV =96 RFC2518 bis February 2002 = =20 Namespace: DAV:=20 Purpose: The lock token associated with a lock.=20 Description: The href contains one or more opaque lock token=20 URIs which all refer to the same lock (i.e., the=20 OpaqueLockToken-URI production in section 6.4).=20 =20 =20 =20 12.1.3 timeout XML Element=20 =20 Name: timeout=20 Namespace: DAV:=20 Purpose: The timeout associated with a lock=20 Value: TimeType ;Defined in section 23.2.=20 =20 =20 =20 12.2 collection XML Element=20 =20 Name: collection=20 Namespace: DAV:=20 Purpose: Identifies the associated resource as a collection. The=20 resourcetype property of a collection resource MUST have=20 this value. =20 =20 =20 =20 12.3 href XML Element=20 =20 Name: href=20 Namespace: DAV:=20 Purpose: Identifies the content of the element as a URI.=20 Value: URI ; See section 3.2.1 of [RFC2068]=20 =20 =20 =20 12.4 link XML Element=20 =20 Name: link=20 Namespace: DAV:=20 Purpose: Identifies the property as a link and contains the source=20 and destination of that link.=20 Description: The link XML element is used to provide the=20 sources and destinations of a link. The name of the=20 =20 Expires Aug 2002 58=20 WebDAV =96 RFC2518 bis February 2002 = =20 property containing the link XML element provides the type=20 of the link. Link is a multi-valued element, so multiple=20 links may be used together to indicate multiple links with=20 the same type. The values in the href XML elements inside=20 the src and dst XML elements of the link XML element MUST=20 NOT be rejected if they point to resources which do not=20 exist.=20 =20 =20 =20 12.4.1 dst XML Element=20 =20 Name: dst=20 Namespace: DAV:=20 Purpose: Indicates the destination of a link=20 Value: URI=20 =20 =20 =20 12.4.2 src XML Element=20 =20 Name: src=20 Namespace: DAV:=20 Purpose: Indicates the source of a link.=20 Value: URI=20 =20 =20 =20 12.5 lockentry XML Element=20 =20 Name: lockentry=20 Namespace: DAV:=20 Purpose: Defines the types of locks that can be used with the=20 resource.=20 =20 =20 =20 12.6 lockinfo XML Element=20 =20 Name: lockinfo=20 Namespace: DAV:=20 Purpose: The lockinfo XML element is used with a LOCK method to=20 specify the type of lock the client wishes to have created.=20 =20 Expires Aug 2002 59=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 =20 12.7 lockscope XML Element=20 =20 Name: lockscope=20 Namespace: DAV:=20 Purpose: Specifies whether a lock is an exclusive lock, or a shared=20 lock.=20 =20 =20 =20 12.7.1 exclusive XML Element=20 =20 Name: exclusive=20 Namespace: DAV:=20 Purpose: Specifies an exclusive lock=20 =20 =20 =20 12.7.2 shared XML Element=20 =20 Name: shared=20 Namespace: DAV:=20 Purpose: Specifies a shared lock=20 =20 =20 =20 12.8 locktype XML Element=20 =20 Name: locktype=20 Namespace: DAV:=20 Purpose: Specifies the access type of a lock. At present, this=20 specification only defines one lock type, the write lock.=20 =20 =20 =20 =20 Expires Aug 2002 60=20 WebDAV =96 RFC2518 bis February 2002 = =20 12.8.1 write XML Element=20 =20 Name: write=20 Namespace: DAV:=20 Purpose: Specifies a write lock.=20 =20 =20 =20 12.9 multistatus XML Element=20 =20 Name: multistatus=20 Namespace: DAV:=20 Purpose: Contains multiple response messages.=20 Description: The responsedescription at the top level is=20 used to provide a general message describing the=20 overarching nature of the response. If this value is=20 available an application may use it instead of presenting=20 the individual response descriptions contained within the=20 responses.=20 =20 =20 =20 12.9.1 response XML Element=20 =20 Name: response=20 Namespace: DAV:=20 Purpose: Holds a single response describing the effect of a method=20 on resource and/or its properties.=20 Description: A particular href MUST NOT appear more than=20 once as the child of a response XML element under a=20 multistatus XML element. This requirement is necessary in=20 order to keep processing costs for a response to linear=20 time. Essentially, this prevents having to search in order=20 to group together all the responses by href. There are,=20 however, no requirements regarding ordering based on href=20 values.=20 =20 =20 =20 12.9.1.1 propstat XML Element=20 =20 Name: propstat=20 Namespace: DAV:=20 =20 Expires Aug 2002 61=20 WebDAV =96 RFC2518 bis February 2002 = =20 Purpose: Groups together a prop and status element that is=20 associated with a particular href element. =20 Description: The propstat XML element MUST contain one prop=20 XML element and one status XML element. The contents of=20 the prop XML element MUST only list the names of properties=20 to which the result in the status element applies.=20 =20 =20 =20 12.9.1.2 status XML Element=20 =20 Name: status=20 Namespace: DAV:=20 Purpose: Holds a single HTTP status-line=20 Value: status-line ;status-line defined in [RFC2068]=20 =20 =20 =20 12.9.2 responsedescription XML Element=20 =20 Name: responsedescription=20 Namespace: DAV:=20 Purpose: Contains a message that can be displayed to the user=20 explaining the nature of the response.=20 Description: This XML element provides information suitable=20 to be presented to a user.=20 =20 =20 =20 12.10 owner XML Element=20 =20 Name: owner=20 Namespace: DAV:=20 Purpose: Provides information about the principal taking out a lock.=20 Description: The owner XML element provides information=20 sufficient for either directly contacting a principal (such=20 as a telephone number or Email URI), or for discovering the=20 principal (such as the URL of a homepage) who owns a lock.=20 =20 =20 =20 12.11 prop XML element=20 =20 Name: prop=20 Namespace: DAV:=20 =20 Expires Aug 2002 62=20 WebDAV =96 RFC2518 bis February 2002 = =20 Purpose: Contains properties related to a resource.=20 Description: The prop XML element is a generic container for=20 properties defined on resources. All elements inside a=20 prop XML element MUST define properties related to the=20 resource. No other elements may be used inside of a prop=20 element.=20 =20 =20 =20 12.12 propertyupdate XML element=20 =20 Name: propertyupdate=20 Namespace: DAV:=20 Purpose: Contains a request to alter the properties on a resource.=20 Description: This XML element is a container for the=20 information required to modify the properties on the=20 resource. This XML element is multi-valued.=20 =20 =20 =20 12.12.1 remove XML element=20 =20 Name: remove=20 Namespace: DAV:=20 Purpose: Lists the DAV properties to be removed from a resource.=20 Description: Remove instructs that the properties specified=20 in prop should be removed. Specifying the removal of a=20 property that does not exist is not an error. All the XML=20 elements in a prop XML element inside of a remove XML=20 element MUST be empty, as only the names of properties to=20 be removed are required.=20 =20 =20 =20 12.12.2 set XML element=20 =20 Name: set=20 Namespace: DAV:=20 Purpose: Lists the DAV property values to be set for a resource.=20 Description: The set XML element MUST contain only a prop=20 XML element. The elements contained by the prop XML=20 element inside the set XML element MUST specify the name=20 and value of properties that are set on the resource=20 identified by Request-URI. If a property already exists=20 then its value is replaced. Language tagging information in=20 =20 Expires Aug 2002 63=20 WebDAV =96 RFC2518 bis February 2002 = =20 the property's value (in the "xml:lang" attribute, if=20 present) MUST be persistently stored along with the=20 property, and MUST be subsequently retrievable using=20 PROPFIND.=20 =20 =20 =20 12.13 propfind XML Element=20 =20 Name: propfind=20 Namespace: DAV:=20 Purpose: Specifies the properties to be returned from a PROPFIND=20 method. Two special elements are specified for use with=20 propfind, allprop and propname. If prop is used inside=20 propfind it MUST only contain property names, not values.=20 =20 =20 =20 12.13.1 allprop XML Element=20 =20 Name: allprop=20 Namespace: DAV:=20 Purpose: The allprop XML element specifies that all property names=20 and values on the resource are to be returned.=20 =20 =20 =20 12.13.2 propname XML Element=20 =20 Name: propname=20 Namespace: DAV:=20 Purpose: The propname XML element specifies that only a list of=20 property names on the resource is to be returned.=20 =20 =20 =20 =20 =20 Expires Aug 2002 64=20 WebDAV =96 RFC2518 bis February 2002 = =20 13 DAV Properties=20 =20 For DAV properties, the name of the property is also the same as the=20 name of the XML element that contains its value. In the section=20 below, the final line of each section gives the element type=20 declaration using the format defined in [REC-XML]. The "Value"=20 field, where present, specifies further restrictions on the=20 allowable contents of the XML element using BNF (i.e., to further=20 restrict the values of a PCDATA element).=20 =20 13.1 creationdate Property=20 =20 Name: creationdate=20 Namespace: DAV:=20 Purpose: Records the time and date the resource was created.=20 Value: date-time ; See Appendix 2=20 Description: The creationdate property should be defined on=20 all DAV compliant resources. If present, it contains a=20 timestamp of the moment when the resource was created=20 (i.e., the moment it had non-null state).=20 =20 =20 =20 13.2 displayname Property=20 =20 Name: displayname=20 Namespace: DAV:=20 Purpose: Provides a name for the resource that is suitable for=20 presentation to a user.=20 Description: The displayname property should be defined on=20 all DAV compliant resources. If present, the property=20 contains a description of the resource that is suitable for=20 presentation to a user.=20 =20 =20 =20 13.3 getcontentlanguage Property=20 =20 Name: getcontentlanguage=20 Namespace: DAV:=20 Purpose: Contains the Content-Language header returned by a GET=20 without accept headers=20 Description: The getcontentlanguage property MUST be defined=20 on any DAV compliant resource that returns the Content- Language header on a GET.=20 =20 Expires Aug 2002 65=20 WebDAV =96 RFC2518 bis February 2002 = =20 Value: language-tag ;language-tag is defined in section 14.13 of=20 [RFC2068]=20 =20 =20 =20 13.4 getcontentlength Property=20 =20 Name: getcontentlength=20 Namespace: DAV:=20 Purpose: Contains the Content-Length header returned by a GET=20 without accept headers.=20 Description: The getcontentlength property MUST be defined=20 on any DAV compliant resource that returns the Content- Length header in response to a GET.=20 Value: content-length ; see section 14.14 of [RFC2068]=20 =20 =20 =20 13.5 getcontenttype Property=20 =20 Name: getcontenttype=20 Namespace: DAV:=20 Purpose: Contains the Content-Type header returned by a GET without=20 accept headers.=20 Description: This getcontenttype property MUST be defined on=20 any DAV compliant resource that returns the Content-Type=20 header in response to a GET.=20 Value: media-type ; defined in section 3.7 of [RFC2068]=20 =20 =20 =20 13.6 getetag Property=20 =20 Name: getetag=20 Namespace: DAV:=20 Purpose: Contains the ETag header returned by a GET without accept=20 headers.=20 Description: The getetag property MUST be defined on any DAV=20 compliant resource that returns the Etag header.=20 Value: entity-tag ; defined in section 3.11 of [RFC2068]=20 =20 =20 =20 =20 Expires Aug 2002 66=20 WebDAV =96 RFC2518 bis February 2002 = =20 13.7 getlastmodified Property=20 =20 Name: getlastmodified=20 Namespace: DAV:=20 Purpose: Contains the Last-Modified header returned by a GET method=20 without accept headers.=20 Description: Note that the last-modified date on a resource=20 may reflect changes in any part of the state of the=20 resource, not necessarily just a change to the response to=20 the GET method. For example, a change in a property may=20 cause the last-modified date to change. The getlastmodified=20 property MUST be defined on any DAV compliant resource that=20 returns the Last-Modified header in response to a GET.=20 Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]=20 =20 =20 =20 13.8 lockdiscovery Property=20 =20 Name: lockdiscovery=20 Namespace: DAV:=20 Purpose: Describes the active locks on a resource=20 Description: The lockdiscovery property returns a listing of=20 who has a lock, what type of lock he has, the timeout type=20 and the time remaining on the timeout, and the associated=20 lock token. The server is free to withhold any or all of=20 this information if the requesting principal does not have=20 sufficient access rights to see the requested data.=20 =20 =20 =20 13.8.1 Example - Retrieving the lockdiscovery Property=20 =20 >>Request=20 =20 PROPFIND /container/ HTTP/1.1=20 Host: www.foo.bar=20 Content-Length: xxxx=20 Content-Type: text/xml; charset=3D"utf-8"=20 =20 =20 =20 =20 =20 =20 >>Response=20 =20 Expires Aug 2002 67=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 http://www.foo.bar/container/=20 =20 =20 =20 =20 =20 =20 0=20 Jane Smith=20 Infinite=20 =20 =20 opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76=20 =20 =20 =20 =20 =20 HTTP/1.1 200 OK=20 =20 =20 =20 =20 This resource has a single exclusive write lock on it, with an=20 infinite timeout.=20 =20 13.9 resourcetype Property=20 =20 Name: resourcetype=20 Namespace: DAV:=20 Purpose: Specifies the nature of the resource.=20 Description: The resourcetype property MUST be defined on=20 all DAV compliant resources. The default value is empty.=20 =20 =20 =20 =20 Expires Aug 2002 68=20 WebDAV =96 RFC2518 bis February 2002 = =20 13.10 source Property=20 =20 Name: source=20 Namespace: DAV:=20 Purpose: The destination of the source link identifies the resource=20 that contains the unprocessed source of the link=92s source. = Description: The source of the link (src) is typically the=20 URI of the output resource on which the link is defined,=20 and there is typically only one destination (dst) of the=20 link, which is the URI where the unprocessed source of the=20 resource may be accessed. When more than one link=20 destination exists, this specification asserts no policy on=20 ordering.=20 =20 =20 =20 13.10.1 Example - A source Property=20 =20 =20 =20 =20 =20 Source=20 http://foo.bar/program=20 http://foo.bar/src/main.c=20 =20 =20 Library=20 http://foo.bar/program=20 http://foo.bar/src/main.lib=20 =20 =20 Makefile=20 http://foo.bar/program=20 http://foo.bar/src/makefile=20 =20 =20 =20 =20 In this example the resource http://foo.bar/program has a source=20 property that contains three links. Each link contains three=20 elements, two of which, src and dst, are part of the DAV schema=20 defined in this document, and one which is defined by the schema=20 http://www.foocorp.com/project/ (Source, Library, and Makefile). A=20 client which only implements the elements in the DAV spec will not=20 understand the foocorp elements and will ignore them, thus seeing=20 the expected source and destination links. An enhanced client may=20 =20 Expires Aug 2002 69=20 WebDAV =96 RFC2518 bis February 2002 = =20 know about the foocorp elements and be able to present the user with=20 additional information about the links. This example demonstrates=20 the power of XML markup, allowing element values to be enhanced=20 without breaking older clients.=20 =20 13.11 supportedlock Property=20 =20 Name: supportedlock=20 Namespace: DAV:=20 Purpose: To provide a listing of the lock capabilities supported by=20 the resource.=20 Description: The supportedlock property of a resource=20 returns a listing of the combinations of scope and access=20 types which may be specified in a lock request on the=20 resource. Note that the actual contents are themselves=20 controlled by access controls so a server is not required=20 to provide information the client is not authorized to see.=20 =20 =20 =20 13.11.1 Example - Retrieving the supportedlock Property=20 =20 >>Request=20 =20 PROPFIND /container/ HTTP/1.1=20 Host: www.foo.bar=20 Content-Length: xxxx=20 Content-Type: text/xml; charset=3D"utf-8"=20 =20 =20 =20 =20 =20 =20 >>Response=20 =20 HTTP/1.1 207 Multi-Status=20 Content-Type: text/xml; charset=3D"utf-8"=20 Content-Length: xxxx=20 =20 =20 =20 =20 http://www.foo.bar/container/=20 =20 =20 =20 =20 Expires Aug 2002 70=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 HTTP/1.1 200 OK=20 =20 =20 =20 =20 =20 14 Instructions for Processing XML in DAV =20 =20 All DAV compliant resources MUST ignore any unknown XML element and=20 all its children encountered while processing a DAV method that uses=20 XML as its command language.=20 =20 This restriction also applies to the processing, by clients, of DAV=20 property values where unknown XML elements SHOULD be ignored unless=20 the property's schema declares otherwise.=20 =20 This restriction does not apply to setting dead DAV properties on=20 the server where the server MUST record unknown XML elements.=20 =20 Additionally, this restriction does not apply to the use of XML=20 where XML happens to be the content type of the entity body, for=20 example, when used as the body of a PUT.=20 =20 Since XML can be transported as text/xml or application/xml, a DAV=20 server MUST accept DAV method requests with XML parameters=20 transported as either text/xml or application/xml, and DAV client=20 MUST accept XML responses using either text/xml or application/xml.=20 =20 15 DAV Compliance Classes=20 =20 A DAV compliant resource can choose from two classes of compliance. =20 A client can discover the compliance classes of a resource by=20 executing OPTIONS on the resource, and examining the "DAV" header=20 which is returned.=20 =20 Since this document describes extensions to the HTTP/1.1 protocol,=20 minimally all DAV compliant resources, clients, and proxies MUST be=20 compliant with [RFC2068].=20 =20 =20 Expires Aug 2002 71=20 WebDAV =96 RFC2518 bis February 2002 = =20 Compliance classes are not necessarily sequential. A resource that=20 is class 2 compliant must also be class 1 compliant; but if=20 additional compliance classes are defined later, a resource that is=20 class 1, 2, and 4 compliant might not be class 3 compliant. Also=20 note that identifiers other than numbers may be used as compliance=20 class identifiers.=20 =20 15.1 Class 1=20 =20 A class 1 compliant resource MUST meet all "MUST" requirements in=20 all sections of this document.=20 =20 Class 1 compliant resources MUST return, at minimum, the value "1"=20 in the DAV header on all responses to the OPTIONS method.=20 =20 15.2 Class 2=20 =20 A class 2 compliant resource MUST meet all class 1 requirements and=20 support the LOCK method, the supportedlock property, the=20 lockdiscovery property, the Time-Out response header and the Lock- Token request header. A class "2" compliant resource SHOULD also=20 support the Time-Out request header and the owner XML element.=20 =20 Class 2 compliant resources MUST return, at minimum, the values "1"=20 and "2" in the DAV header on all responses to the OPTIONS method.=20 =20 =20 16 Internationalization Considerations=20 =20 In the realm of internationalization, this specification complies=20 with the IETF Character Set Policy [RFC2277]. In this specification,=20 human-readable fields can be found either in the value of a=20 property, or in an error message returned in a response entity body. = In both cases, the human-readable content is encoded using XML,=20 which has explicit provisions for character set tagging and=20 encoding, and requires that XML processors read XML elements=20 encoded, at minimum, using the UTF-8 [UTF-8] encoding of the ISO=20 10646 multilingual plane. XML examples in this specification=20 demonstrate use of the charset parameter of the Content-Type header,=20 as defined in [RFC2376], as well as the XML "encoding" attribute,=20 which together provide charset identification information for MIME=20 and XML processors.=20 =20 XML also provides a language tagging capability for specifying the=20 language of the contents of a particular XML element. XML uses=20 either IANA registered language tags (see [RFC1766]) or ISO 639=20 language tags [ISO-639] in the "xml:lang" attribute of an XML=20 element to identify the language of its content and attributes.=20 =20 =20 Expires Aug 2002 72=20 WebDAV =96 RFC2518 bis February 2002 = =20 WebDAV applications MUST support the character set tagging,=20 character set encoding, and the language tagging functionality of=20 the XML specification. Implementors of WebDAV applications are=20 strongly encouraged to read "XML Media Types" [RFC2376] for=20 instruction on which MIME media type to use for XML transport, and=20 on use of the charset parameter of the Content-Type header.=20 =20 Names used within this specification fall into three categories:=20 names of protocol elements such as methods and headers, names of XML=20 elements, and names of properties. Naming of protocol elements=20 follows the precedent of HTTP, using English names encoded in=20 USASCII for methods and headers. Since these protocol elements are=20 not visible to users, and are in fact simply long token identifiers,=20 they do not need to support encoding in multiple character sets. =20 Similarly, though the names of XML elements used in this=20 specification are English names encoded in UTF-8, these names are=20 not visible to the user, and hence do not need to support multiple=20 character set encodings.=20 =20 The name of a property defined on a resource is a URI. Although=20 some applications (e.g., a generic property viewer) will display=20 property URIs directly to their users, it is expected that the=20 typical application will use a fixed set of properties, and will=20 provide a mapping from the property name URI to a human-readable=20 field when displaying the property name to a user. It is only in=20 the case where the set of properties is not known ahead of time that=20 an application need display a property name URI to a user. We=20 recommend that applications provide human-readable property names=20 wherever feasible.=20 =20 For error reporting, we follow the convention of HTTP/1.1 status=20 codes, including with each status code a short, English description=20 of the code (e.g., 423 (Locked)). While the possibility exists that=20 a poorly crafted user agent would display this message to a user,=20 internationalized applications will ignore this message, and display=20 an appropriate message in the user's language and character set.=20 =20 Since interoperation of clients and servers does not require locale=20 information, this specification does not specify any mechanism for=20 transmission of this information.=20 =20 =20 17 Security Considerations=20 =20 This section is provided to detail issues concerning security=20 implications of which WebDAV applications need to be aware.=20 =20 All of the security considerations of HTTP/1.1 (discussed in=20 [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In=20 addition, the security risks inherent in remote authoring require=20 stronger authentication technology, introduce several new privacy=20 =20 Expires Aug 2002 73=20 WebDAV =96 RFC2518 bis February 2002 = =20 concerns, and may increase the hazards from poor server design.=20 These issues are detailed below.=20 =20 17.1 Authentication of Clients=20 =20 Due to their emphasis on authoring, WebDAV servers need to use=20 authentication technology to protect not just access to a network=20 resource, but the integrity of the resource as well. Furthermore,=20 the introduction of locking functionality requires support for=20 authentication.=20 =20 A password sent in the clear over an insecure channel is an=20 inadequate means for protecting the accessibility and integrity of a=20 resource as the password may be intercepted. Since Basic=20 authentication for HTTP/1.1 performs essentially clear text=20 transmission of a password, Basic authentication MUST NOT be used to=20 authenticate a WebDAV client to a server unless the connection is=20 secure. Furthermore, a WebDAV server MUST NOT send Basic=20 authentication credentials in a WWW-Authenticate header unless the=20 connection is secure. Examples of secure connections include a=20 Transport Layer Security (TLS) connection employing a strong cipher=20 suite with mutual authentication of client and server, or a=20 connection over a network which is physically secure, for example,=20 an isolated network in a building with restricted access.=20 =20 WebDAV applications MUST support the Digest authentication scheme=20 [RFC2069]. Since Digest authentication verifies that both parties to=20 a communication know a shared secret, a password, without having to=20 send that secret in the clear, Digest authentication avoids the=20 security problems inherent in Basic authentication while providing a=20 level of authentication which is useful in a wide range of=20 scenarios.=20 =20 17.2 Denial of Service=20 =20 Denial of service attacks are of special concern to WebDAV servers. =20 WebDAV plus HTTP enables denial of service attacks on every part of=20 a system's resources.=20 =20 The underlying storage can be attacked by PUTting extremely large=20 files.=20 =20 Asking for recursive operations on large collections can attack=20 processing time.=20 =20 Making multiple pipelined requests on multiple connections can=20 attack network connections.=20 =20 WebDAV servers need to be aware of the possibility of a denial of=20 service attack at all levels.=20 =20 =20 Expires Aug 2002 74=20 WebDAV =96 RFC2518 bis February 2002 = =20 17.3 Security through Obscurity=20 =20 WebDAV provides, through the PROPFIND method, a mechanism for=20 listing the member resources of a collection. This greatly=20 diminishes the effectiveness of security or privacy techniques that=20 rely only on the difficulty of discovering the names of network=20 resources. Users of WebDAV servers are encouraged to use access=20 control techniques to prevent unwanted access to resources, rather=20 than depending on the relative obscurity of their resource names.=20 =20 17.4 Privacy Issues Connected to Locks=20 =20 When submitting a lock request a user agent may also submit an owner=20 XML field giving contact information for the person taking out the=20 lock (for those cases where a person, rather than a robot, is taking=20 out the lock). This contact information is stored in a lockdiscovery=20 property on the resource, and can be used by other collaborators to=20 begin negotiation over access to the resource. However, in many=20 cases this contact information can be very private, and should not=20 be widely disseminated. Servers SHOULD limit read access to the=20 lockdiscovery property as appropriate. Furthermore, user agents=20 SHOULD provide control over whether contact information is sent at=20 all, and if contact information is sent, control over exactly what=20 information is sent.=20 =20 17.5 Privacy Issues Connected to Properties=20 =20 Since property values are typically used to hold information such as=20 the author of a document, there is the possibility that privacy=20 concerns could arise stemming from widespread access to a resource's=20 property data. To reduce the risk of inadvertent release of private=20 information via properties, servers are encouraged to develop access=20 control mechanisms that separate read access to the resource body=20 and read access to the resource's properties. This allows a user to=20 control the dissemination of their property data without overly=20 restricting access to the resource's contents.=20 =20 17.6 Reduction of Security due to Source Link=20 =20 HTTP/1.1 warns against providing read access to script code because=20 it may contain sensitive information. Yet WebDAV, via its source=20 link facility, can potentially provide a URI for script resources so=20 they may be authored. For HTTP/1.1, a server could reasonably=20 prevent access to source resources due to the predominance of read- only access. WebDAV, with its emphasis on authoring, encourages=20 read and write access to source resources, and provides the source=20 link facility to identify the source. This reduces the security=20 benefits of eliminating access to source resources. Users and=20 administrators of WebDAV servers should be very cautious when=20 =20 Expires Aug 2002 75=20 WebDAV =96 RFC2518 bis February 2002 = =20 allowing remote authoring of scripts, limiting read and write access=20 to the source resources to authorized principals.=20 =20 17.7 Implications of XML External Entities =20 =20 XML supports a facility known as "external entities", defined in=20 section 4.2.2 of [REC-XML], which instruct an XML processor to=20 retrieve and perform an inline include of XML located at a=20 particular URI. An external XML entity can be used to append or=20 modify the document type declaration (DTD) associated with an XML=20 document. An external XML entity can also be used to include XML=20 within the content of an XML document. For non-validating XML, such=20 as the XML used in this specification, including an external XML=20 entity is not required by [REC-XML]. However, [REC-XML] does state=20 that an XML processor may, at its discretion, include the external=20 XML entity.=20 =20 External XML entities have no inherent trustworthiness and are=20 subject to all the attacks that are endemic to any HTTP GET request. = Furthermore, it is possible for an external XML entity to modify the=20 DTD, and hence affect the final form of an XML document, in the=20 worst case significantly modifying its semantics, or exposing the=20 XML processor to the security risks discussed in [RFC2376].=20 Therefore, implementers must be aware that external XML entities=20 should be treated as untrustworthy. =20 =20 There is also the scalability risk that would accompany a widely=20 deployed application which made use of external XML entities. In=20 this situation, it is possible that there would be significant=20 numbers of requests for one external XML entity, potentially=20 overloading any server which fields requests for the resource=20 containing the external XML entity.=20 =20 17.8 Risks Connected with Lock Tokens=20 =20 This specification, in section 6.4, requires the use of Universal=20 Unique Identifiers (UUIDs) for lock tokens, in order to guarantee=20 their uniqueness across space and time. UUIDs, as defined in [ISO- 11578], contain a "node" field which "consists of the IEEE address,=20 usually the host address. For systems with multiple IEEE 802 nodes,=20 any available node address can be used." Since a WebDAV server will=20 issue many locks over its lifetime, the implication is that it will=20 also be publicly exposing its IEEE 802 address.=20 =20 There are several risks associated with exposure of IEEE 802=20 addresses. Using the IEEE 802 address:=20 =20 * It is possible to track the movement of hardware from subnet to=20 subnet.=20 =20 =20 Expires Aug 2002 76=20 WebDAV =96 RFC2518 bis February 2002 = =20 * It may be possible to identify the manufacturer of the hardware=20 running a WebDAV server.=20 =20 * It may be possible to determine the number of each type of=20 computer running WebDAV.=20 Section 6.4.1 of this specification details an alternate mechanism=20 for generating the "node" field of a UUID without using an IEEE 802=20 address, which alleviates the risks associated with exposure of IEEE=20 802 addresses by using an alternate source of uniqueness.=20 =20 =20 18 IANA Considerations=20 =20 This document defines two namespaces, the namespace of property=20 names, and the namespace of WebDAV-specific XML elements used within=20 property values. =20 =20 URIs are used for both names, for several reasons. Assignment of a=20 URI does not require a request to a central naming authority, and=20 hence allow WebDAV property names and XML elements to be quickly=20 defined by any WebDAV user or application. URIs also provide a=20 unique address space, ensuring that the distributed users of WebDAV=20 will not have collisions among the property names and XML elements=20 they create.=20 =20 This specification defines a distinguished set of property names and=20 XML elements that are understood by all WebDAV applications. The=20 property names and XML elements in this specification are all=20 derived from the base URI DAV: by adding a suffix to this URI, for=20 example, DAV:creationdate for the "creationdate" property.=20 =20 This specification also defines a URI scheme for the encoding of=20 lock tokens, the opaquelocktoken URI scheme described in section=20 6.4.=20 =20 To ensure correct interoperation based on this specification, IANA=20 must reserve the URI namespaces starting with "DAV:" and with=20 "opaquelocktoken:" for use by this specification, its revisions, and=20 related WebDAV specifications.=20 =20 19 Intellectual Property=20 =20 The following notice is copied from RFC 2026 [RFC2026], section=20 10.4, and describes the position of the IETF concerning intellectual=20 property claims made against this document.=20 =20 The IETF takes no position regarding the validity or scope of any=20 intellectual property or other rights that might be claimed to=20 pertain to the implementation or use other technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; neither does it represent that it=20 =20 Expires Aug 2002 77=20 WebDAV =96 RFC2518 bis February 2002 = =20 has made any effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track and=20 standards-related documentation can be found in BCP-11. Copies of=20 claims of rights made available for publication and any assurances=20 of licenses to be made available, or the result of an attempt made=20 to obtain a general license or permission for the use of such=20 proprietary rights by implementors or users of this specification=20 can be obtained from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights which may cover technology that may be required to practice=20 this standard. Please address the information to the IETF Executive=20 Director.=20 =20 20 Acknowledgements=20 =20 A specification such as this thrives on piercing critical review and=20 withers from apathetic neglect. The authors gratefully acknowledge=20 the contributions of the following people, whose insights were so=20 valuable at every stage of our work.=20 =20 Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan=20 Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith=20 Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee=20 Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan=20 Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis=20 Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van=20 der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur,=20 Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas=20 Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon=20 Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith=20 Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick,=20 Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar=20 Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood.=20 =20 Two from this list deserve special mention. The contributions by=20 Larry Masinter have been invaluable, both in helping the formation=20 of the working group and in patiently coaching the authors along the=20 way. In so many ways he has set high standards we have toiled to=20 meet. The contributions of Judith Slein in clarifying the=20 requirements, and in patiently reviewing draft after draft, both=20 improved this specification and expanded our minds on document=20 management.=20 =20 We would also like to thank John Turner for developing the XML DTD.=20 =20 =20 Expires Aug 2002 78=20 WebDAV =96 RFC2518 bis February 2002 = =20 21 References=20 =20 21.1 Normative References=20 =20 [RFC1766] H. T. Alvestrand, "Tags for the Identification of=20 Languages." RFC 1766. Uninett. March, 1995.=20 =20 [RFC2277] H. T. Alvestrand, "IETF Policy on Character Sets and=20 Languages." RFC 2277, BCP 18. Uninett. January, 1998.=20 =20 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate=20 Requirement Levels." RFC 2119, BCP 14. Harvard University.=20 March, 1997.=20 =20 [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform=20 Resource Identifiers (URI): Generic Syntax." RFC 2396.=20 MIT/LCS, U.C. Irvine, Xerox. August, 1998.=20 =20 [REC-XML]T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible=20 Markup Language (XML)." World Wide Web Consortium=20 Recommendation REC-xml-19980210.=20 http://www.w3.org/TR/1998/REC-xml-19980210.=20 =20 [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in=20 XML" World Wide Web Consortium Recommendation REC-xml-names.=20 http://www.w3.org/TR/REC-xml-names-19990114/=20 =20 [RFC2069] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A.=20 Luotonen, E. Sink, and L. Stewart. "An Extension to HTTP :=20 Digest Access Authentication" RFC 2069. Northwestern=20 University, CERN, Spyglass Inc., Microsoft Corp., Netscape=20 Communications Corp., Spyglass Inc., Open Market Inc. January=20 1997.=20 =20 [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T.=20 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC=20 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997. =20 =20 [ISO-639] ISO (International Organization for Standardization).=20 ISO 639:1988. "Code for the representation of names of=20 languages."=20 =20 [ISO-8601] ISO (International Organization for Standardization).=20 ISO 8601:1988. "Data elements and interchange formats -=20 Information interchange - Representation of dates and times."=20 =20 Expires Aug 2002 79=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 [ISO-11578] ISO (International Organization for Standardization).=20 ISO/IEC 11578:1996. "Information technology - Open Systems=20 Interconnection - Remote Procedure Call (RPC)"=20 =20 [RFC2141] R. Moats, "URN Syntax." RFC 2141. AT&T. May, 1997.=20 =20 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode=20 and ISO 10646." RFC 2279. Alis Technologies. January, 1998.=20 =20 21.2 Informational References=20 =20 [RFC2026] S. Bradner, "The Internet Standards Process - Revision=20 3." RFC 2026, BCP 9. Harvard University. October, 1996.=20 =20 [RFC1807] R. Lasher, D. Cohen, "A Format for Bibliographic=20 Records," RFC 1807. Stanford, Myricom. June, 1995.=20 =20 [WF] C. Lagoze, "The Warwick Framework: A Container Architecture=20 for Diverse Sets of Metadata", D-Lib Magazine, July/August=20 1996.=20 http://www.dlib.org/dlib/july96/lagoze/07lagoze.html=20 =20 [USMARC] Network Development and MARC Standards, Office, ed.=20 1994. "USMARC Format for Bibliographic Data", 1994.=20 Washington, DC: Cataloging Distribution Service, Library of=20 Congress.=20 =20 [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS=20 Label Distribution Label Syntax and Communication Protocols"=20 Version 1.1, World Wide Web Consortium Recommendation REC- PICS-labels-961031. http://www.w3.org/pub/WWW/TR/REC-PICS- labels-961031.html.=20 =20 [RFC2291] J. A. Slein, F. Vitali, E. J. Whitehead, Jr., D.=20 Durand, "Requirements for Distributed Authoring and=20 Versioning Protocol for the World Wide Web." RFC 2291. Xerox,=20 Univ. of Bologna, U.C. Irvine, Boston Univ. February, 1998.=20 =20 [RFC2413] S. Weibel, J. Kunze, C. Lagoze, M. Wolf, "Dublin Core=20 Metadata for Resource Discovery." RFC 2413. OCLC, UCSF,=20 Cornell, Reuters. September, 1998.=20 =20 [RFC2376] E. Whitehead, M. Murata, "XML Media Types." RFC 2376.=20 U.C. Irvine, Fuji Xerox Info. Systems. July 1998.=20 =20 =20 Expires Aug 2002 80=20 WebDAV =96 RFC2518 bis February 2002 = =20 22 Authors' Addresses=20 =20 Y. Y. Goland=20 Microsoft Corporation=20 One Microsoft Way=20 Redmond, WA 98052-6399=20 Email: yarong@microsoft.com=20 =20 E. J. Whitehead, Jr.=20 Dept. Of Information and Computer Science=20 University of California, Irvine=20 Irvine, CA 92697-3425=20 Email: ejw@ics.uci.edu=20 =20 A. Faizi=20 Netscape=20 685 East Middlefield Road=20 Mountain View, CA 94043=20 Email: asad@netscape.com=20 =20 S. R. Carter=20 Novell=20 1555 N. Technology Way=20 M/S ORM F111=20 Orem, UT 84097-2399=20 Email: srcarter@novell.com=20 =20 D. Jensen=20 Novell=20 1555 N. Technology Way=20 M/S ORM F111=20 Orem, UT 84097-2399=20 Email: dcjensen@novell.com=20 =20 L. Dusseault=20 Xythos Software, Inc.=20 25 Maiden Lane, 6th floor=20 San Francisco=20 Email: lisa@xythos.com=20 =20 Expires Aug 2002 81=20 WebDAV =96 RFC2518 bis February 2002 = =20 23 Appendices=20 =20 23.1 Appendix 1 - WebDAV Document Type Definition=20 =20 This section provides a document type definition, following the=20 rules in [REC-XML], for the XML elements used in the protocol stream=20 and in the values of properties. It collects the element definitions=20 given in sections 12 and 13.=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Expires Aug 2002 82=20 WebDAV =96 RFC2518 bis February 2002 = =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 ]>=20 =20 23.2 Appendix 2 - ISO 8601 Date and Time Profile =20 =20 The creationdate property specifies the use of the ISO 8601 date=20 format [ISO-8601]. This section defines a profile of the ISO 8601=20 date format for use with this specification. This profile is quoted=20 from an Internet-Draft by Chris Newman, and is mentioned here to=20 properly attribute his work.=20 =20 date-time =3D full-date "T" full-time=20 =20 full-date =3D date-fullyear "-" date-month "-" date-mday=20 full-time =3D partial-time time-offset=20 =20 date-fullyear =3D 4DIGIT=20 date-month =3D 2DIGIT ; 01-12=20 date-mday =3D 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on=20 month/year=20 time-hour =3D 2DIGIT ; 00-23=20 time-minute =3D 2DIGIT ; 00-59=20 =20 Expires Aug 2002 83=20 WebDAV =96 RFC2518 bis February 2002 = =20 time-second =3D 2DIGIT ; 00-59, 00-60 based on leap second rules = time-secfrac =3D "." 1*DIGIT=20 time-numoffset =3D ("+" / "-") time-hour ":" time-minute=20 time-offset =3D "Z" / time-numoffset=20 =20 partial-time =3D time-hour ":" time-minute ":" time-second=20 [time-secfrac]=20 =20 Numeric offsets are calculated as local time minus UTC (Coordinated=20 Universal Time). So the equivalent time in UTC can be determined by=20 subtracting the offset from the local time. For example, 18:50:00- 04:00 is the same time as 22:58:00Z. =20 =20 If the time in UTC is known, but the offset to local time is=20 unknown, this can be represented with an offset of "-00:00". This=20 differs from an offset of "Z" which implies that UTC is the=20 preferred reference point for the specified time. =20 =20 =20 Expires Aug 2002 84=20 WebDAV =96 RFC2518 bis February 2002 = =20 23.3 Appendix 3 - Notes on Processing XML Elements=20 =20 23.3.1 Notes on Empty XML Elements=20 =20 XML supports two mechanisms for indicating that an XML element does=20 not have any content. The first is to declare an XML element of the=20 form . The second is to declare an XML element of the form=20 . The two XML elements are semantically identical.=20 =20 It is a violation of the XML specification to use the form if = the associated DTD declares the element to be EMPTY (e.g., ). If such a statement is included, then the empty element=20 format, must be used. If the element is not declared to be=20 EMPTY, then either form or may be used for empty = elements.=20 =20 23.3.2 Notes on Illegal XML Processing=20 =20 XML is a flexible data format that makes it easy to submit data that=20 appears legal but in fact is not. The philosophy of "Be flexible in=20 what you accept and strict in what you send" still applies, but it=20 must not be applied inappropriately. XML is extremely flexible in=20 dealing with issues of white space, element ordering, inserting new=20 elements, etc. This flexibility does not require extension,=20 especially not in the area of the meaning of elements.=20 =20 There is no kindness in accepting illegal combinations of XML=20 elements. At best it will cause an unwanted result and at worst it=20 can cause real damage.=20 =20 23.3.2.1 Example - XML Syntax Error=20 =20 The following request body for a PROPFIND method is illegal.=20 =20 =20 =20 =20 =20 =20 =20 The definition of the propfind element only allows for the allprop=20 or the propname element, not both. Thus the above is an error and=20 must be responded to with a 400 (Bad Request).=20 =20 Imagine, however, that a server wanted to be "kind" and decided to=20 pick the allprop element as the true element and respond to it. A=20 client running over a bandwidth limited line who intended to execute=20 a propname would be in for a big surprise if the server treated the=20 command as an allprop.=20 =20 =20 Expires Aug 2002 85=20 WebDAV =96 RFC2518 bis February 2002 = =20 Additionally, if a server were lenient and decided to reply to this =20 request, the results would vary randomly from server to server, with=20 some servers executing the allprop directive, and others executing=20 the propname directive. This reduces interoperability rather than=20 increasing it.=20 =20 23.3.2.2 Example - Unknown XML Element=20 =20 The previous example was illegal because it contained two elements=20 that were explicitly banned from appearing together in the propfind=20 element. However, XML is an extensible language, so one can imagine=20 new elements being defined for use with propfind. Below is the=20 request body of a PROPFIND and, like the previous example, must be=20 rejected with a 400 (Bad Request) by a server that does not=20 understand the expired-props element.=20 =20 =20 =20 =20 =20 =20 To understand why a 400 (Bad Request) is returned let us look at the=20 request body as the server unfamiliar with expired-props sees it.=20 =20 =20 =20 =20 =20 As the server does not understand the expired-props element,=20 according to the WebDAV-specific XML processing rules specified in=20 section 14, it must ignore it. Thus the server sees an empty=20 propfind, which by the definition of the propfind element is=20 illegal.=20 =20 Please note that had the extension been additive it would not=20 necessarily have resulted in a 400 (Bad Request). For example,=20 imagine the following request body for a PROPFIND:=20 =20 =20 =20 =20 *boss*=20 =20 =20 The previous example contains the fictitious element leave-out. Its=20 purpose is to prevent the return of any property whose name matches=20 the submitted pattern. If the previous example were submitted to a=20 =20 Expires Aug 2002 86=20 WebDAV =96 RFC2518 bis February 2002 = =20 server unfamiliar with leave-out, the only result would be that the=20 leave-out element would be ignored and a propname would be executed.=20 =20 =20 24 Full Copyright Statement=20 =20 Copyright (C) The Internet Society (1999). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implementation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English.=20 =20 The limited permissions granted above are perpetual and will not be=20 revoked by the Internet Society or its successors or assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 =20 =20 =20 Expires Aug 2002 87=20 ------=_NextPart_000_0140_01C1B9FE.04CB2B20-- From w3c-dist-auth-request@w3.org Wed Feb 20 16:55:33 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21568 for ; Wed, 20 Feb 2002 16:55:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15300; Wed, 20 Feb 2002 16:54:31 -0500 (EST) Resent-Date: Wed, 20 Feb 2002 16:54:31 -0500 (EST) Resent-Message-Id: <200202202154.QAA15300@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 QAA15252 for ; Wed, 20 Feb 2002 16:54:10 -0500 (EST) Received: from ladon.host4u.net (ladon.host4u.net [216.71.64.24]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA14846 for ; Wed, 20 Feb 2002 16:54:10 -0500 Received: from win2k (24-205-161-181.riv-dyn.charterpipeline.com [24.205.161.181]) by ladon.host4u.net (8.11.6/8.11.6) with SMTP id g1KLqGd15025 for ; Wed, 20 Feb 2002 15:52:16 -0600 Message-ID: <002f01c1ba59$153cdb10$6401a8c0@win2k> From: "John Glavin" To: Date: Wed, 20 Feb 2002 13:53:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: MOVE command fails with 502 bad gateway on apache server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5918 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 Hello, With one particular server my DAV client is getting a "502 bad gateway" error on the MOVE command. With most other DAV servers the client doesn't have a problem so I am wondering if anyone can think of a reason why it would be failing on this server. BTW the rename(MOVE) with WebFolders fails as well but webfolders falls back to uploading the file to a different name to accomplish the rename operation. The owner of the server doesn't believe that they are running any proxies on the server although I don't know how to verify that. The server reports itself as "Server: Apache/1.3.23 (WCS NFS Patch) (Unix) DAV/1.0.3" My MOVE command looks like this MOVE /share/test/file.txt HTTP/1.1 Destination: http://shares.serverinquestion.com/share/test/newfile.txt Host: shares.serverinquestion.com Overwrite: F User-Agent: WebDrive Accept-Language: en-us Translate: f Pragma: no-cache Connection: close HTTP/1.1 502 Bad Gateway Thank you, John Glavin South River Technologies john@southrivertech.com http://www.southrivertech.com From w3c-dist-auth-request@w3.org Thu Feb 21 03:38:27 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10963 for ; Thu, 21 Feb 2002 03:38:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA03376; Thu, 21 Feb 2002 03:37:11 -0500 (EST) Resent-Date: Thu, 21 Feb 2002 03:37:11 -0500 (EST) Resent-Message-Id: <200202210837.DAA03376@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 DAA03345 for ; Thu, 21 Feb 2002 03:36:50 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA26364 for ; Thu, 21 Feb 2002 03:36:49 -0500 Received: (qmail 19619 invoked by uid 0); 21 Feb 2002 08:36:17 -0000 Received: from p5082596d.dip.t-dialin.net (HELO lisa) (80.130.89.109) by mail.gmx.net (mp001-rz3) with SMTP; 21 Feb 2002 08:36:17 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Thu, 21 Feb 2002 09:36:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5919 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 Lisa, I'm not happy with: XML's support for multiple human languages, using the “xml:lang” attribute (in the case of WebDAV properties, this attribute is placed on the ‘prop’ element), handles cases where the same character set is employed by multiple human languages. and I don't think we have reached consensus for this change. In my opinion, this is an attempt to re-define how XML works (without sound technical reason). In XML, attributes in the special XML namespace have scoping. It shouldn't matter where an xml:lang is defined as long as it's in scope of the current node. I *do* agree, that the RFC might be more specific about this, but then it should just quote what XML (and Canonical XML) have to say about it. Also, this should be defined in an update of the definition of a property's value (what's in, what's out?). Julian From w3c-dist-auth-request@w3.org Thu Feb 21 03:53:30 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11150 for ; Thu, 21 Feb 2002 03:53:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA04757; Thu, 21 Feb 2002 03:52:35 -0500 (EST) Resent-Date: Thu, 21 Feb 2002 03:52:35 -0500 (EST) Resent-Message-Id: <200202210852.DAA04757@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 DAA04708 for ; Thu, 21 Feb 2002 03:52:15 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA28483 for ; Thu, 21 Feb 2002 03:52:14 -0500 Received: (qmail 17244 invoked by uid 0); 21 Feb 2002 08:51:43 -0000 Received: from p5082596d.dip.t-dialin.net (HELO lisa) (80.130.89.109) by mail.gmx.net (mp015-rz3) with SMTP; 21 Feb 2002 08:51:43 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Thu, 21 Feb 2002 09:51:41 +0100 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RFC2518bis: allprop deprecated (4.1) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5920 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, I don't agree at all with the deprecation, and I don't think that there was consensus about this. The draft says: Clients MUST not send allprop requests in any form (either the empty body PROPFIND or the specific allprop element), because allprop is being removed. WebDAV servers increasingly have expensively-calculated or lengthy properties (see DeltaV and ACL specifications [TODO: ref RFC when available]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what properties exist, and request named properties when retrieving values. A WebDAV server MAY omit certain live properties from other specifications when responding to an allprop request from an older client, and MAY return only custom (dead) properties and those defined in this specification. In particular: "WebDAV servers increasingly have expensively-calculated or lengthy properties (see DeltaV and ACL specifications [TODO: ref RFC when available]) and do not return all properties already." -> This is an argument for *restricting* the set of properties returned on allprop, not for removing the feature (and that's what deltaV does). "Instead, WebDAV clients can use propname requests to discover what properties exist, and request named properties when retrieving values." -> And the benefit is? The client will issue two calls: first it will use propname to find the list of properties. Computing whether a live property exists maybe as expensive as computing it (for instance, to find out whether something is checked in/out). *Then* it will submit PROPFIND / prop will all these properties. So as compared to the current situation, the server may have to compute things twice which wouldn't have been computed at all before (since asking for allprop wouldn't require computing live deltaV properties). -> Even leaving the propname vs live properties issue out, this doesn't make sense. You are removing a working and interoperable protocol feature without sound reason. As a fallback you offer a workaround which requires at least one additional trip to the server, possibly heavy computation on the client (computing the set of all property names on the members of a collection) and then additional marshalling (when I do a PROPFIND/prop with a long list of (dead) property names on a collection with depth 1, the server will have to 404-status them for many collection members). -> I agree that PROPFIND needs to be cleaned up, but this is not the way to go. The draft continues with: "A WebDAV server MAY omit certain live properties from other specifications when responding to an allprop request from an older client, and MAY return only custom (dead) properties and those defined in this specification." -> I think this may make sense. We will however need a way to get all dead properties and a set of named properties with a single request (see [1]). We may also have to find a way for a client to discover that something is a live property. [1] From w3c-dist-auth-request@w3.org Thu Feb 21 07:03:50 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14276 for ; Thu, 21 Feb 2002 07:03:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA23810; Thu, 21 Feb 2002 07:02:38 -0500 (EST) Resent-Date: Thu, 21 Feb 2002 07:02:38 -0500 (EST) Resent-Message-Id: <200202211202.HAA23810@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 HAA23755 for ; Thu, 21 Feb 2002 07:02:20 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA19458 for ; Thu, 21 Feb 2002 07:02:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14246; Thu, 21 Feb 2002 07:02:18 -0500 (EST) Message-Id: <200202211202.HAA14246@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 21 Feb 2002 07:02:18 -0500 Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5921 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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : HTTP Extensions for Distributed Authoring û WebDAV RFC2518 bis Author(s) : Y. GOLAND et al. Filename : draft-ietf-webdav-rfc2518bis-00.txt Pages : 87 Date : 20-Feb-02 WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes only minor revisions mostly due to interoperability experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-rfc2518bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020220141108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-rfc2518bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020220141108.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Feb 21 07:37:13 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15029 for ; Thu, 21 Feb 2002 07:37:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA27129; Thu, 21 Feb 2002 07:36:18 -0500 (EST) Resent-Date: Thu, 21 Feb 2002 07:36:18 -0500 (EST) Resent-Message-Id: <200202211236.HAA27129@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 HAA27087 for ; Thu, 21 Feb 2002 07:36:04 -0500 (EST) Received: from server8.software-ag.de (server8.software-ag.de [193.26.193.23]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA23437 for ; Thu, 21 Feb 2002 07:36:03 -0500 Received: from daehub01.software-ag.de by server8.software-ag.de; (8.9.3/8.9.3) id NAA27880; Thu, 21 Feb 2002 13:35:15 +0100 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2650.21) id <165248GP>; Thu, 21 Feb 2002 13:36:01 +0100 Message-ID: From: "Hermann, Eckehard" To: w3c-dist-auth@w3c.org Date: Thu, 21 Feb 2002 13:36:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: read/write privileges Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5922 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 all, the ACL Standard says under 3.7 that the DAV:write privileg MUST NOT contain the DAV:read privileg. What sense does it make to give someone the right for doing updates or delete a resource but not to allow to read the resource? What is the reason that a DAV:write most not contain a DAV:read? regards Eckehard From w3c-dist-auth-request@w3.org Thu Feb 21 09:07:07 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17678 for ; Thu, 21 Feb 2002 09:07:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA13601; Thu, 21 Feb 2002 09:06:08 -0500 (EST) Resent-Date: Thu, 21 Feb 2002 09:06:08 -0500 (EST) Resent-Message-Id: <200202211406.JAA13601@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 JAA13580 for ; Thu, 21 Feb 2002 09:05:55 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA18930 for ; Thu, 21 Feb 2002 09:05:55 -0500 Received: (qmail 12711 invoked by uid 0); 21 Feb 2002 14:05:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 21 Feb 2002 14:05:24 -0000 From: "Julian Reschke" To: Date: Thu, 21 Feb 2002 15:05:24 +0100 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 V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: Shared locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5923 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 Lisa Dusseault > Sent: Saturday, February 16, 2002 11:13 PM > To: w3c-dist-auth@w3.org > Subject: Shared locks > > > > Has independent interoperability been demonstrated with RFC2518 shared > locks? If you believe it has been, what are the clients and servers with > which it was demonstrated? I don't think so. Our server passes the tests in the Litmus test (as does moddav, I think), but I'm not aware of any client actually requesting shared locks... Julian From w3c-dist-auth-request@w3.org Thu Feb 21 17:03:25 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05781 for ; Thu, 21 Feb 2002 17:03:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14178; Thu, 21 Feb 2002 16:53:26 -0500 (EST) Resent-Date: Thu, 21 Feb 2002 16:53:26 -0500 (EST) Resent-Message-Id: <200202212153.QAA14178@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 QAA14129 for ; Thu, 21 Feb 2002 16:53:07 -0500 (EST) Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA22601 for ; Thu, 21 Feb 2002 16:53:07 -0500 Received: from unx51.staff.flyingcroc.net (unx51.staff.flyingcroc.net [207.246.150.51]) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with ESMTP id NAA95562; Thu, 21 Feb 2002 13:52:34 -0800 (PST) Received: (from erk@localhost) by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g1LLo0060943; Thu, 21 Feb 2002 13:50:00 -0800 (PST) (envelope-from erk) To: dav-dev@lyra.org, w3c-dist-auth@w3.org Cc: Julian Reschke In-Reply-To: References: Organization: Accretive Technology Group From: Erik Seaberg Date: 21 Feb 2002 13:50:00 -0800 Message-ID: <86wux6mrnb.fsf@unx51.staff.flyingcroc.net> Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: [dav-dev] Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5924 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: Julian Reschke writes: > - In moddav (correct me if I'm wrong), people may be creating > resources by directly accessing the filesystem. says # NOTE: the file repository is considered "private" to mod_dav and the # web server. Modifying files via FTP or through filesystem commands # should not be allowed. > - Broken clients may use request/destination URIs which are not > encoded in UTF-8 I thought (per RFCs 2396 and 2616) the "http" scheme just specifies a mapping for each part of the URL from US-ASCII to a sequence of octets, and the mapping from those octets back to characters (if any!) is at the whim of the server. %-escaped UTF-8 is *recommended* for new schemes (and for HTML that embeds URLs containing invalid non-ASCII characters), but a server that uses Latin-15 should be able to send Latin-15 in PROPFIND responses without having a client complain about or mangle perfectly workable URLs just because it can't display them nicely. From w3c-dist-auth-request@w3.org Thu Feb 21 18:18:08 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07120 for ; Thu, 21 Feb 2002 18:18:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23745; Thu, 21 Feb 2002 18:17:06 -0500 (EST) Resent-Date: Thu, 21 Feb 2002 18:17:06 -0500 (EST) Resent-Message-Id: <200202212317.SAA23745@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 SAA23704 for ; Thu, 21 Feb 2002 18:16:58 -0500 (EST) 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 SAA01765 for ; Thu, 21 Feb 2002 18:16:58 -0500 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 PAA10886 for ; Thu, 21 Feb 2002 15:16:59 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 21 Feb 2002 15:15:22 -0800 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: RE: Shared locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5925 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 have added to the accept2 list, so future emails from Frank at this email address will go straight through to the list. - Jim -----Original Message----- From: Frank Biederich [mailto:frank.biederich@adobe.com] Sent: Thursday, February 21, 2002 7:14 AM To: w3c-dist-auth@w3c.org Subject: [Moderator Action] RE: Shared locks Julian - > I don't think so. > > Our server passes the tests in the Litmus test (as does moddav, I think), > but I'm not aware of any client actually requesting shared locks... FYI, Adobe GoLive (version 5 or later) is able to do it. No workflow is built upon this feature, but you're able to set shared locks on resources using the included WebDAV browser. Best, Frank -- Frank Biederich Adobe Systems frank.biederich@adobe.com http://www.adobe.com http://www.adobe.com/golive From w3c-dist-auth-request@w3.org Thu Feb 21 21:07:13 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09266 for ; Thu, 21 Feb 2002 21:07:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA19314; Wed, 20 Feb 2002 12:31:00 -0500 (EST) Resent-Date: Wed, 20 Feb 2002 12:31:00 -0500 (EST) Resent-Message-Id: <200202201731.MAA19314@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 MAA19284 for ; Wed, 20 Feb 2002 12:30:46 -0500 (EST) 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 MAA28768 for ; Wed, 20 Feb 2002 12:30:46 -0500 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 JAA04345 for ; Wed, 20 Feb 2002 09:30:49 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 20 Feb 2002 09:29:14 -0800 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: Re: MOVE command fails with 502 bad gateway on apache server Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5915 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 have added "john@webdrive.com" to the accept2 list. - Jim -----Original Message----- From: John Glavin [mailto:john@webdrive.com] Sent: Wednesday, February 20, 2002 12:04 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] MOVE command fails with 502 bad gateway on apache server Hello, With one particular server my DAV client is getting a "502 bad gateway" error on the MOVE command. With most other DAV servers the client doesn't have a problem so I am wondering if anyone can think of a reason why it would be failing on this server. BTW the rename(MOVE) with WebFolders fails as well but webfolders falls back to uploading the file to a different name to accomplish the rename operation. The owner of the server doesn't believe that they are running any proxies on the server although I don't know how to verify that. The server reports itself as "Server: Apache/1.3.23 (WCS NFS Patch) (Unix) DAV/1.0.3" My MOVE command looks like this MOVE /share/test/file.txt HTTP/1.1 Destination: http://shares.serverinquestion.com/share/test/newfile.txt Host: shares.serverinquestion.com Overwrite: F User-Agent: WebDrive Accept-Language: en-us Translate: f Pragma: no-cache Connection: close HTTP/1.1 502 Bad Gateway Thank you, John Glavin South River Technologies john@southrivertech.com http://www.southrivertech.com From w3c-dist-auth-request@w3.org Fri Feb 22 00:08:49 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13803 for ; Fri, 22 Feb 2002 00:08:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA07093; Tue, 19 Feb 2002 18:51:55 -0500 (EST) Resent-Date: Tue, 19 Feb 2002 18:51:55 -0500 (EST) Resent-Message-Id: <200202192351.SAA07093@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 SAA07068 for ; Tue, 19 Feb 2002 18:51:35 -0500 (EST) Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA26309 for ; Tue, 19 Feb 2002 18:51:34 -0500 Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19) id <14CZW3CW>; Tue, 19 Feb 2002 15:46:17 -0800 Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3c.org Date: Tue, 19 Feb 2002 15:46:50 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5911 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 don't think it is or should be a requirement that all proprietary properties be live properties. Alan -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, February 18, 2002 11:47 PM To: Babich, Alan; w3c-dist-auth@w3c.org Subject: RE: Using DAV namespace for proprietary properties I see. Could you please explain this position? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > Sent: Monday, February 18, 2002 9:25 PM > To: w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > "Would it be permissible to assume that properties in the DAV: namespace > *never* are dead properties, allowing to skip this step?" > > I don't think so. > > Alan Babich > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, February 18, 2002 6:29 AM > To: w3c-dist-auth@w3c.org > Subject: Using DAV namespace for proprietary properties > > > Hi, > > currently RFC2518 is silent on this issue. > > However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies > can be extended by arbitrary XML elements, which can be ignored by the > message recipient, an XML element in the DAV namespace MUST NOT be used in > the request or response body of a versioning method unless that > XML element > is explicitly defined in an IETF RFC." > > I think something similar needs to be added to the revision to RFC2518. > > Looking at current implementations I notice that the Microsoft Webfolder > client (sigh!) does a PROPFIND on no less than then 10 proprietary > properties placed into the DAV: namespace ([2]), of which it only seems to > *use* one (DAV:ishidden). Without wiring special knowledge about these > attributes into a server, it will usually have to consult the resource's > dead properties (just to find out that these don't exist). Would it be > permissible to assume that properties in the DAV: namespace > *never* are dead > properties, allowing to skip this step? > > Julian > > > [1] > [2] From w3c-dist-auth-request@w3.org Fri Feb 22 03:36:51 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24483 for ; Fri, 22 Feb 2002 03:36:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA10814; Wed, 20 Feb 2002 05:39:39 -0500 (EST) Resent-Date: Wed, 20 Feb 2002 05:39:39 -0500 (EST) Resent-Message-Id: <200202201039.FAA10814@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 FAA10740 for ; Wed, 20 Feb 2002 05:39:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA28088 for ; Wed, 20 Feb 2002 05:39:01 -0500 Received: (qmail 14163 invoked by uid 0); 20 Feb 2002 10:38:29 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 20 Feb 2002 10:38:29 -0000 From: "Julian Reschke" To: "Greg Stein" Cc: "Peter Gillis" , , , Date: Wed, 20 Feb 2002 11:38:28 +0100 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: <20020219185240.W15965@lyra.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: [dav-dev] Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5914 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 Greg, what you describe is a scenario where - the server preserves whatever octet sequence was used in a URL - the clients are consistent in what they send/expect However, thinks are more complicated. - In moddav (correct me if I'm wrong), people may be creating resources by directly accessing the filesystem. If, for instance, I create a filename containing "A umlaut", and the filesystem's filename encoding is ISO-8859-1, I'll have the octet %c4 in the name. Returning %c4 in the PROPFIND response in the general case will not work (because the client doesn't know about URL character encodings, so it must use what the RFCs say, and that is UTF-8). - Broken clients may use request/destination URIs which are not encoded in UTF-8 (this may apply to older versions of Microsoft clients). So you basically have the choice of failing the request if the octet stream doesn't UTF-8-decode, or you can try to workaround the problem by making assumptions about what the encoding in the request may have been. As this issue is coming up every few weeks and as almost every server / client I've seen in the last few months has some bug in this regard, it should certainly clarified in the RFC2518 revision. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Wednesday, February 20, 2002 3:53 AM > To: Julian Reschke > Cc: Peter Gillis; dav-dev@lyra.org; w3c-dist-auth@w3.org; > I20568n@mindshare.intraspect.com > Subject: Re: [dav-dev] Problem with OfficeXP and Accented characters > > > On Wed, Feb 13, 2002 at 09:31:37PM +0100, Julian Reschke wrote: > >... > > > From: dav-dev-admin@lyra.org > [mailto:dav-dev-admin@lyra.org]On Behalf Of > > > Peter Gillis > > > Sent: Wednesday, February 13, 2002 8:46 PM > >... > > > I am having a problem with Microsoft Web Folders after the > client installs > > > Office XP on their machine and file names with accented characters are > > > involved. Our server has been working in the past with earlier > > > implementations of Web Folders without a problem, however, > when the client > > > machine is upgraded to Office XP, a document that was accessible > > > previously > > > is now not found. I have tracked the problem down to the > fact that Web > > > Folders is encoding the URI value a second time before sending > > > the request, > > > which then causes it not to be found on our server. For example: > > > > > > In the folder listing we send back the following property: > > > > > > /dav/webdav/%E8%E2temp%C9.xls > > > > Isn't this wrong in the first place? My understanding is that you should > > send URL-encoded UTF-8. > > Nope. > > The filename is in an "original character set". That is then encoded into > octets for the URL. That transformation is not specified > anywhere. Ideally, > it is "original -> UTF-8", but nobody says it must be. In fact, I > would say > it should match whatever encoding was used for the Request-URI > (but that is > not specified/defined in the request, so you're out of luck again). > > Once you have octets, then you perform the URL-escaping (using '%xx'). > > After that, you need to transform the URL into the character set of the > response body. That is usually UTF-8, but it is possible to have > the XML in > a different character set (provided it is specified on the Content-Type > response header). > > Finally, you must XML-escape the UTF-8 characters of the URL you're > inserting (e.g. translate '&' to '&') so that you can embed the UTF-8 > content into the XML response. > > > A long time ago, I captured this as a start of a technical FAQ. See: > http://www.webdav.org/other/techfaq.html > > Specifically, the second section. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Fri Feb 22 03:50:26 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24669 for ; Fri, 22 Feb 2002 03:50:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA16169; Fri, 22 Feb 2002 03:49:32 -0500 (EST) Resent-Date: Fri, 22 Feb 2002 03:49:32 -0500 (EST) Resent-Message-Id: <200202220849.DAA16169@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 DAA16138 for ; Fri, 22 Feb 2002 03:49:13 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA02037 for ; Fri, 22 Feb 2002 03:49:12 -0500 Received: (qmail 936 invoked by uid 0); 22 Feb 2002 08:48:41 -0000 Received: from pd9e51559.dip.t-dialin.net (HELO lisa) (217.229.21.89) by mail.gmx.net (mp005-rz3) with SMTP; 22 Feb 2002 08:48:41 -0000 From: "Julian Reschke" To: "Babich, Alan" , Date: Fri, 22 Feb 2002 09:48:36 +0100 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.2600.0000 In-Reply-To: Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5926 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 Alan, that's fine. My position is that proprietary properties MUST not use the DAV: namespace. If my server can rely on this, it can report all DAV: properties it doesn't know as "not found" without even bothering to ask the persistence layer. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > Sent: Wednesday, February 20, 2002 12:47 AM > To: w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > I don't think it is or should be a requirement that all > proprietary properties be live properties. > > Alan > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, February 18, 2002 11:47 PM > To: Babich, Alan; w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > I see. > > Could you please explain this position? > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > > Sent: Monday, February 18, 2002 9:25 PM > > To: w3c-dist-auth@w3c.org > > Subject: RE: Using DAV namespace for proprietary properties > > > > > > "Would it be permissible to assume that properties in the DAV: namespace > > *never* are dead properties, allowing to skip this step?" > > > > I don't think so. > > > > Alan Babich > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Monday, February 18, 2002 6:29 AM > > To: w3c-dist-auth@w3c.org > > Subject: Using DAV namespace for proprietary properties > > > > > > Hi, > > > > currently RFC2518 is silent on this issue. > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and > response bodies > > can be extended by arbitrary XML elements, which can be ignored by the > > message recipient, an XML element in the DAV namespace MUST NOT > be used in > > the request or response body of a versioning method unless that > > XML element > > is explicitly defined in an IETF RFC." > > > > I think something similar needs to be added to the revision to RFC2518. > > > > Looking at current implementations I notice that the Microsoft Webfolder > > client (sigh!) does a PROPFIND on no less than then 10 proprietary > > properties placed into the DAV: namespace ([2]), of which it > only seems to > > *use* one (DAV:ishidden). Without wiring special knowledge about these > > attributes into a server, it will usually have to consult the resource's > > dead properties (just to find out that these don't exist). Would it be > > permissible to assume that properties in the DAV: namespace > > *never* are dead > > properties, allowing to skip this step? > > > > Julian > > > > > > [1] > > g-20.1.htm > #_Toc524830510> > [2] > From w3c-dist-auth-request@w3.org Fri Feb 22 04:14:48 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24914 for ; Fri, 22 Feb 2002 04:14:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA20315; Fri, 22 Feb 2002 04:13:22 -0500 (EST) Resent-Date: Fri, 22 Feb 2002 04:13:22 -0500 (EST) Resent-Message-Id: <200202220913.EAA20315@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 EAA20266 for ; Fri, 22 Feb 2002 04:13:00 -0500 (EST) 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 EAA05271 for ; Fri, 22 Feb 2002 04:13:00 -0500 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 22 Feb 2002 10:12:27 +0100 Date: Fri, 22 Feb 2002 10:12:29 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dav-dev@lyra.org, w3c-dist-auth@w3.org, Julian Reschke To: Erik Seaberg From: Stefan Eissing In-Reply-To: <86wux6mrnb.fsf@unx51.staff.flyingcroc.net> Message-Id: <4BE05E01-2774-11D6-BF5C-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: [dav-dev] Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5927 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 Am Donnerstag den, 21. Februar 2002, um 22:50, schrieb Erik Seaberg: > Julian Reschke writes: > [...] >> - Broken clients may use request/destination URIs which are not >> encoded in UTF-8 > > I thought (per RFCs 2396 and 2616) the "http" scheme just specifies a > mapping for each part of the URL from US-ASCII to a sequence of > octets, and the mapping from those octets back to characters (if any!) > is at the whim of the server. %-escaped UTF-8 is *recommended* for > new schemes (and for HTML that embeds URLs containing invalid > non-ASCII characters), but a server that uses Latin-15 should be able > to send Latin-15 in PROPFIND responses without having a client > complain about or mangle perfectly workable URLs just because it can't > display them nicely. What you say is correct from a pure protocol perspective. Nowhere in RFC 2518 or 2616 is anything said about decoded URIs. And RFC 2396 says that there is no such thing as a decoded URI. All true. The problem appears when you put a user interface on top of webdav. Be it a Windows WebFolder or an OS X mounted volume. People just expect nowadays that they can use Umlauts and the Euro sign in filenames. They even expect that they can do that in Windows and Linux and MacOS and will all see the same file on a particular server. As I see it, this requires a standard character encoding for conversion of user input to URIs on the client side, namely UTF-8. For the broken clients, Julian is talking about, it would be good if servers make the effort to detect non-UTF-8 encoding and apply characters conversion (most likely from 8859-1). I've seen Tomcat looking for charset parameters in URIs to detect char encoding. I'm not sure if I really understand what they are trying to do. It looks like clients could use GET /test/folder/%d7%c4;charset=ISO-8859-7 HTTP/1.1 in their requests. Does anyone know more about that? //Stefan From w3c-dist-auth-request@w3.org Fri Feb 22 12:22:04 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12215 for ; Fri, 22 Feb 2002 12:22:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26833; Fri, 22 Feb 2002 12:20:45 -0500 (EST) Resent-Date: Fri, 22 Feb 2002 12:20:45 -0500 (EST) Resent-Message-Id: <200202221720.MAA26833@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 MAA26803 for ; Fri, 22 Feb 2002 12:20:32 -0500 (EST) 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 MAA28917 for ; Fri, 22 Feb 2002 12:20:32 -0500 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 JAA26389 for ; Fri, 22 Feb 2002 09:20:34 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 22 Feb 2002 09:18:59 -0800 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: Re: Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5928 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: tai@pekoe.iij.ad.jp [mailto:tai@pekoe.iij.ad.jp]On Behalf Of Taisuke Yamada Sent: Friday, February 22, 2002 3:29 AM To: dav-dev@lyra.org; w3c-dist-auth@w3.org Subject: [Moderator Action] Re: Problem with OfficeXP and Accented characters > As I see it, this requires a standard character encoding for conversion > of user input to URIs on the client side, namely UTF-8. I agree. Both URI and HTTP spec need to update RFC to clarify UTF-8 is the only charset allowed before and after URI-escaping. I think there's an draft for URI spec clarifying this. > I've seen Tomcat looking for charset parameters in URIs to detect > char encoding. I'm not sure if I really understand what they are > trying to do. It looks like clients could use > > GET /test/folder/%d7%c4;charset=ISO-8859-7 HTTP/1.1 > > in their requests. Does anyone know more about that? Just FYI, WebDAV client that comes with MacOS X speaks things like PROPFIND /?charset=X-MAC-JAPANESE HTTP/1.1 to pass out encoding information. Obviously, this only works with their own WebDAV service (iDisk). For now, you can workaround the problem by using mod_encoding module which does encoding detection/conversion prior to mod_dav processing. Conversion is done based on useragent/encoding pair and priority settings in httpd.conf. This will make things interoperable at least in local environment. # Please see my other posting for the download URL. -- Taisuke Yamada Internet Initiative Japan Inc., Technical Planning Division From w3c-dist-auth-request@w3.org Fri Feb 22 12:22:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12245 for ; Fri, 22 Feb 2002 12:22:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26897; Fri, 22 Feb 2002 12:21:14 -0500 (EST) Resent-Date: Fri, 22 Feb 2002 12:21:14 -0500 (EST) Resent-Message-Id: <200202221721.MAA26897@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 MAA26852 for ; Fri, 22 Feb 2002 12:21:01 -0500 (EST) 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 MAA29001 for ; Fri, 22 Feb 2002 12:21:01 -0500 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 JAA26515 for ; Fri, 22 Feb 2002 09:21:04 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 22 Feb 2002 09:19:29 -0800 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: Re: [dav-dev] Re: Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5929 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: Chris Sharp [mailto:csharp@apple.com] Sent: Friday, February 22, 2002 8:02 AM To: Taisuke Yamada Cc: dav-dev@lyra.org; w3c-dist-auth@w3.org Subject: [Moderator Action] Re: [dav-dev] Re: Problem with OfficeXP and Accented characters The only reason we had to do this is that we translate UTF8 into MacOS Roman on the backend. One of the requirements was for OS9 users to be able to interop with OSX and vica versa via the iDisk service. In most cases, we use this hint "x-mac-japanese" to unambiguously translate UTF8 into Mac OS Roman. Further, for some reason OSX prefers fully decomposed UTF8 on the return trip. Based on a suggestion from Julian, I believe, we only provide this functionality to non OSX based User-Agents. Chris On Friday, February 22, 2002, at 03:22 AM, Taisuke Yamada wrote: > Just FYI, WebDAV client that comes with MacOS X speaks things like > > PROPFIND /?charset=X-MAC-JAPANESE HTTP/1.1 From w3c-dist-auth-request@w3.org Fri Feb 22 14:03:21 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17016 for ; Fri, 22 Feb 2002 14:03:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA08223; Fri, 22 Feb 2002 14:01:27 -0500 (EST) Resent-Date: Fri, 22 Feb 2002 14:01:27 -0500 (EST) Resent-Message-Id: <200202221901.OAA08223@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 OAA08120 for ; Fri, 22 Feb 2002 14:01:04 -0500 (EST) 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 OAA14971 for ; Fri, 22 Feb 2002 14:01:04 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA23906 for ; Fri, 22 Feb 2002 13:56:59 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1MJ01I146952 for ; Fri, 22 Feb 2002 14:00:01 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 22 Feb 2002 13:43:36 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/22/2002 02:00:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5930 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: Let me phrase this differently... :-) Does anyone besides Julian... :-) ...feel there is a change in the 2518 spec needed in regard to the following posting by Julian... :-) Please speak up. > currently RFC2518 is silent on this issue. > > However, deltaV says 1.5 [1]: "Although WebDAV request and > response bodies > can be extended by arbitrary XML elements, which can be ignored by the > message recipient, an XML element in the DAV namespace MUST NOT > be used in > the request or response body of a versioning method unless that > XML element > is explicitly defined in an IETF RFC." > > I think something similar needs to be added to the revision to RFC2518. ---------------------------------------------------------------------- To: w3c-dist-auth@w3c.org Message-ID: From: "Jason Crawford" Date: Wed, 20 Feb 2002 15:29:33 -0500 Subject: Re: Using DAV namespace for proprietary properties Do we feel there is a change in the 2518 spec needed in regard to the following posting by Julian... > currently RFC2518 is silent on this issue. > > However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies > can be extended by arbitrary XML elements, which can be ignored by the > message recipient, an XML element in the DAV namespace MUST NOT be used in > the request or response body of a versioning method unless that XML element > is explicitly defined in an IETF RFC." > > I think something similar needs to be added to the revision to RFC2518. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Feb 22 19:48:17 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02627 for ; Fri, 22 Feb 2002 19:48:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA11418; Fri, 22 Feb 2002 19:47:11 -0500 (EST) Resent-Date: Fri, 22 Feb 2002 19:47:11 -0500 (EST) Resent-Message-Id: <200202230047.TAA11418@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 TAA11398 for ; Fri, 22 Feb 2002 19:46:55 -0500 (EST) 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 TAA32689 for ; Fri, 22 Feb 2002 19:46:55 -0500 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 QAA22710; Fri, 22 Feb 2002 16:46:59 -0800 (PST) From: "Jim Whitehead" To: "Jason Crawford" , Date: Fri, 22 Feb 2002 16:45:20 -0800 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 In-Reply-To: Importance: Normal Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5931 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 strongly feel that a revision of RFC 2518 should state that the "dav:" property namespace is reserved for use by IETF-approved Standards-Track specifications, and that client implementations MUST NOT use this namespace for application-specific properties. Pragmatically, I think existing exceptions to this rule should be grandfathered. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, February 22, 2002 10:44 AM > To: w3c-dist-auth@w3c.org > Subject: Re: Using DAV namespace for proprietary properties > > > Let me phrase this differently... :-) > > Does anyone besides Julian... :-) > > ...feel there is a change in the 2518 spec needed in regard to the > following posting by Julian... :-) > > Please speak up. > > > > currently RFC2518 is silent on this issue. > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and > > response bodies > > can be extended by arbitrary XML elements, which can be ignored by the > > message recipient, an XML element in the DAV namespace MUST NOT > > be used in > > the request or response body of a versioning method unless that > > XML element > > is explicitly defined in an IETF RFC." > > > > I think something similar needs to be added to the revision to RFC2518. > > ---------------------------------------------------------------------- > > > > To: w3c-dist-auth@w3c.org > Message-ID: > From: "Jason Crawford" > Date: Wed, 20 Feb 2002 15:29:33 -0500 > Subject: Re: Using DAV namespace for proprietary properties > > Do we feel there is a change in the 2518 spec needed in regard to the > following posting by Julian... > > > > currently RFC2518 is silent on this issue. > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and response > bodies > > can be extended by arbitrary XML elements, which can be ignored by the > > message recipient, an XML element in the DAV namespace MUST NOT be used > in > > the request or response body of a versioning method unless that XML > element > > is explicitly defined in an IETF RFC." > > > > I think something similar needs to be added to the revision to RFC2518. > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Fri Feb 22 21:15:41 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03869 for ; Fri, 22 Feb 2002 21:15:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA16838; Fri, 22 Feb 2002 21:14:50 -0500 (EST) Resent-Date: Fri, 22 Feb 2002 21:14:50 -0500 (EST) Resent-Message-Id: <200202230214.VAA16838@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 VAA16797 for ; Fri, 22 Feb 2002 21:14:33 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-074032.rational.com [130.213.74.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA06749 for ; Fri, 22 Feb 2002 21:14:33 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Fri, 22 Feb 2002 21:12:52 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 21:14:02 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105E4DA06@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 22 Feb 2002 21:14:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5932 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 that this is a problem, and suggest that it be solved by adding the wording from DeltaV to 2518. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, February 20, 2002 3:30 PM To: w3c-dist-auth@w3c.org Subject: Re: Using DAV namespace for proprietary properties Do we feel there is a change in the 2518 spec needed in regard to the following posting by Julian... > currently RFC2518 is silent on this issue. > > However, deltaV says 1.5 [1]: "Although WebDAV request and response bodies > can be extended by arbitrary XML elements, which can be ignored by the > message recipient, an XML element in the DAV namespace MUST NOT be used in > the request or response body of a versioning method unless that XML element > is explicitly defined in an IETF RFC." > > I think something similar needs to be added to the revision to RFC2518. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat Feb 23 10:05:27 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20664 for ; Sat, 23 Feb 2002 10:05:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA16116; Sat, 23 Feb 2002 04:41:19 -0500 (EST) Resent-Date: Sat, 23 Feb 2002 04:41:19 -0500 (EST) Resent-Message-Id: <200202230941.EAA16116@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 EAA15548 for ; Sat, 23 Feb 2002 04:40:09 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA05652 for ; Sat, 23 Feb 2002 03:52:16 -0500 Received: (qmail 8562 invoked by uid 0); 23 Feb 2002 08:52:15 -0000 Received: from pd9e513b7.dip.t-dialin.net (HELO lisa) (217.229.19.183) by mail.gmx.net (mp005-rz3) with SMTP; 23 Feb 2002 08:52:15 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "Jason Crawford" , Date: Sat, 23 Feb 2002 09:52:13 +0100 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5933 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, going back to my original question...: it *is* permissible for a server to - deny setting the property DAV:contentclass (until it is defined in an IETF specification) and to - report "not found" upon PROPFIND without actually *checking* dead properties. Right? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Saturday, February 23, 2002 1:45 AM > To: Jason Crawford; w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > I strongly feel that a revision of RFC 2518 should state that the "dav:" > property namespace is reserved for use by IETF-approved Standards-Track > specifications, and that client implementations MUST NOT use this > namespace > for application-specific properties. > > Pragmatically, I think existing exceptions to this rule should be > grandfathered. > > - Jim > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > Sent: Friday, February 22, 2002 10:44 AM > > To: w3c-dist-auth@w3c.org > > Subject: Re: Using DAV namespace for proprietary properties > > > > > > Let me phrase this differently... :-) > > > > Does anyone besides Julian... :-) > > > > ...feel there is a change in the 2518 spec needed in regard to the > > following posting by Julian... :-) > > > > Please speak up. > > > > > > > currently RFC2518 is silent on this issue. > > > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and > > > response bodies > > > can be extended by arbitrary XML elements, which can be ignored by the > > > message recipient, an XML element in the DAV namespace MUST NOT > > > be used in > > > the request or response body of a versioning method unless that > > > XML element > > > is explicitly defined in an IETF RFC." > > > > > > I think something similar needs to be added to the revision > to RFC2518. > > > > ---------------------------------------------------------------------- > > > > > > > > To: w3c-dist-auth@w3c.org > > Message-ID: > > From: "Jason Crawford" > > Date: Wed, 20 Feb 2002 15:29:33 -0500 > > Subject: Re: Using DAV namespace for proprietary properties > > > > Do we feel there is a change in the 2518 spec needed in regard to the > > following posting by Julian... > > > > > > > currently RFC2518 is silent on this issue. > > > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and response > > bodies > > > can be extended by arbitrary XML elements, which can be ignored by the > > > message recipient, an XML element in the DAV namespace MUST > NOT be used > > in > > > the request or response body of a versioning method unless that XML > > element > > > is explicitly defined in an IETF RFC." > > > > > > I think something similar needs to be added to the revision > to RFC2518. > > > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > > From w3c-dist-auth-request@w3.org Sat Feb 23 18:55:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25435 for ; Sat, 23 Feb 2002 18:55:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA01381; Sat, 23 Feb 2002 18:54:20 -0500 (EST) Resent-Date: Sat, 23 Feb 2002 18:54:20 -0500 (EST) Resent-Message-Id: <200202232354.SAA01381@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 SAA01304 for ; Sat, 23 Feb 2002 18:54:09 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-074032.rational.com [130.213.74.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19483 for ; Sat, 23 Feb 2002 18:54:09 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sat, 23 Feb 2002 18:52:26 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Feb 2002 18:53:38 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105E4DA6F@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sat, 23 Feb 2002 18:53:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: read/write privileges Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5934 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 definition is an attempt to provide some (minimal) common semantics to DAV:read and DAV:write. Without this definition, some servers would implement them as orthogonal privileges, and others would (as you suggest) implement DAV:write as a composite privilege that includes DAV:read. There are some cases where it is reasonable to give DAV:write but not DAV:read privilege to a resource (e.g. a "closed-bid" resource that you can append to, but not see what else has been written there). If a resource is both readable and writeable, then just return both DAV:read and DAV:write as granted privileges. Cheers, Geoff -----Original Message----- From: Hermann, Eckehard [mailto:Eckehard.Hermann@softwareag.com] Sent: Thursday, February 21, 2002 7:36 AM To: w3c-dist-auth@w3c.org Subject: read/write privileges Hi all, the ACL Standard says under 3.7 that the DAV:write privileg MUST NOT contain the DAV:read privileg. What sense does it make to give someone the right for doing updates or delete a resource but not to allow to read the resource? What is the reason that a DAV:write most not contain a DAV:read? regards Eckehard From w3c-dist-auth-request@w3.org Sat Feb 23 18:55:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25443 for ; Sat, 23 Feb 2002 18:55:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA01424; Sat, 23 Feb 2002 18:54:31 -0500 (EST) Resent-Date: Sat, 23 Feb 2002 18:54:31 -0500 (EST) Resent-Message-Id: <200202232354.SAA01424@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 SAA01334 for ; Sat, 23 Feb 2002 18:54:14 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-074032.rational.com [130.213.74.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19487 for ; Sat, 23 Feb 2002 18:54:14 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sat, 23 Feb 2002 18:52:30 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Feb 2002 18:53:42 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105E4DA73@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sat, 23 Feb 2002 18:53:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: IETF meeting: Refreshing locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5935 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: The paragraph referred to was in section 9.8: The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received. Unfortunately, I cannot remember the rationale for removing this paragraph, although it might have been that servers aren't actually doing this in practice? Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Monday, February 18, 2002 7:01 PM To: Julian Reschke Cc: w3c-dist-auth@w3.org Subject: IETF meeting: Refreshing locks What does the following text from the SLC IETF meaning mean? > Refreshing Locks.... > > Consensus was to delete paragraph on lock refresh. > Eric - clients seem to be expecting locks to hang around, when they expire it causes problems. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sun Feb 24 00:47:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29911 for ; Sun, 24 Feb 2002 00:47:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA29412; Sun, 24 Feb 2002 00:44:51 -0500 (EST) Resent-Date: Sun, 24 Feb 2002 00:44:51 -0500 (EST) Resent-Message-Id: <200202240544.AAA29412@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 AAA29391 for ; Sun, 24 Feb 2002 00:44:45 -0500 (EST) Received: from sus-ma1it31.rational.com (ext-074032.rational.com [130.213.74.32]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA22997 for ; Sun, 24 Feb 2002 00:44:45 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Sun, 24 Feb 2002 00:42:57 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Feb 2002 00:44:10 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105E4DA9D@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sun, 24 Feb 2002 00:44:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5936 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 would answer "yes" to both questions. Although some servers may have gone ahead and defined some custom live properties in the DAV: namespace, are there any clients that depend on the ability to set dead properties in the DAV: namespace? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, February 23, 2002 3:52 AM To: Jim Whitehead; Jason Crawford; w3c-dist-auth@w3c.org Subject: RE: Using DAV namespace for proprietary properties So, going back to my original question...: it *is* permissible for a server to - deny setting the property DAV:contentclass (until it is defined in an IETF specification) and to - report "not found" upon PROPFIND without actually *checking* dead properties. Right? > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Saturday, February 23, 2002 1:45 AM > To: Jason Crawford; w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > I strongly feel that a revision of RFC 2518 should state that the "dav:" > property namespace is reserved for use by IETF-approved Standards-Track > specifications, and that client implementations MUST NOT use this > namespace > for application-specific properties. > > Pragmatically, I think existing exceptions to this rule should be > grandfathered. > > - Jim > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > Sent: Friday, February 22, 2002 10:44 AM > > To: w3c-dist-auth@w3c.org > > Subject: Re: Using DAV namespace for proprietary properties > > > > > > Let me phrase this differently... :-) > > > > Does anyone besides Julian... :-) > > > > ...feel there is a change in the 2518 spec needed in regard to the > > following posting by Julian... :-) > > > > Please speak up. > > > > > > > currently RFC2518 is silent on this issue. > > > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and > > > response bodies > > > can be extended by arbitrary XML elements, which can be ignored by the > > > message recipient, an XML element in the DAV namespace MUST NOT > > > be used in > > > the request or response body of a versioning method unless that > > > XML element > > > is explicitly defined in an IETF RFC." > > > > > > I think something similar needs to be added to the revision > to RFC2518. > > > > ---------------------------------------------------------------------- > > > > > > > > To: w3c-dist-auth@w3c.org > > Message-ID: > > From: "Jason Crawford" > > Date: Wed, 20 Feb 2002 15:29:33 -0500 > > Subject: Re: Using DAV namespace for proprietary properties > > > > Do we feel there is a change in the 2518 spec needed in regard to the > > following posting by Julian... > > > > > > > currently RFC2518 is silent on this issue. > > > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and response > > bodies > > > can be extended by arbitrary XML elements, which can be ignored by the > > > message recipient, an XML element in the DAV namespace MUST > NOT be used > > in > > > the request or response body of a versioning method unless that XML > > element > > > is explicitly defined in an IETF RFC." > > > > > > I think something similar needs to be added to the revision > to RFC2518. > > > > > > ------------------------------------------ > > Phone: 914-784-7569, ccjason@us.ibm.com > > > From w3c-dist-auth-request@w3.org Sun Feb 24 11:16:36 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12663 for ; Sun, 24 Feb 2002 11:16:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01315; Sun, 24 Feb 2002 11:11:02 -0500 (EST) Resent-Date: Sun, 24 Feb 2002 11:11:02 -0500 (EST) Resent-Message-Id: <200202241611.LAA01315@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 LAA01294 for ; Sun, 24 Feb 2002 11:10:52 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA13950 for ; Sun, 24 Feb 2002 11:10:52 -0500 Received: (qmail 22011 invoked by uid 0); 24 Feb 2002 16:10:21 -0000 Received: from pd953505e.dip.t-dialin.net (HELO lisa) (217.83.80.94) by mail.gmx.net (mp008-rz3) with SMTP; 24 Feb 2002 16:10:21 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Sun, 24 Feb 2002 17:10:20 +0100 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 V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105E4DA9D@SUS-MA1IT01> Importance: Normal Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5937 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 Clemm, Geoff > Sent: Sunday, February 24, 2002 6:44 AM > To: w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > I would answer "yes" to both questions. Although some servers may > have gone ahead and defined some custom live properties in the DAV: > namespace, are there any clients that depend on the ability to set > dead properties in the DAV: namespace? That woulb really interesting. Guess I'll find out soon :-) From w3c-dist-auth-request@w3.org Sun Feb 24 16:41:25 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16267 for ; Sun, 24 Feb 2002 16:41:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA18062; Sun, 24 Feb 2002 16:37:08 -0500 (EST) Resent-Date: Sun, 24 Feb 2002 16:37:08 -0500 (EST) Resent-Message-Id: <200202242137.QAA18062@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 QAA18031 for ; Sun, 24 Feb 2002 16:36:49 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08449 for ; Sun, 24 Feb 2002 16:36:48 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1OLYmZ14261 for ; Sun, 24 Feb 2002 13:34:48 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1OLYsY06832 for ; Sun, 24 Feb 2002 13:34:54 -0800 (PST) Received: from larrypad ([130.248.184.139]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GS240700.CNA; Sun, 24 Feb 2002 13:36:07 -0800 Reply-To: From: "Larry Masinter" To: "'Jim Whitehead'" , "'WebDAV'" Date: Sun, 24 Feb 2002 13:35:41 -0800 Message-ID: <003801c1bd7b$40f91fa0$3604010a@larrypad> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Subject: RE: [dav-dev] Re: Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5938 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 is important for the WebDAV group to come up with a WebDAV spec that defines character encodings for file names and the relationship of filenames and encodings to URL strings. Don't expect this to be handled by changes to HTTP or URI specifications. From w3c-dist-auth-request@w3.org Sun Feb 24 18:09:03 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16764 for ; Sun, 24 Feb 2002 18:09:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA25907; Sun, 24 Feb 2002 18:04:53 -0500 (EST) Resent-Date: Sun, 24 Feb 2002 18:04:53 -0500 (EST) Resent-Message-Id: <200202242304.SAA25907@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 SAA25882 for ; Sun, 24 Feb 2002 18:04:35 -0500 (EST) 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 SAA17783 for ; Sun, 24 Feb 2002 18:04:35 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA221512; Sun, 24 Feb 2002 18:00:51 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1ON42d118174; Sun, 24 Feb 2002 18:04:02 -0500 To: Cc: "'Jim Whitehead'" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Sun, 24 Feb 2002 17:46:44 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/24/2002 06:04:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: [dav-dev] Re: Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5939 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: > Don't expect this to be handled by changes to HTTP > or URI specifications. It's good to know this. > It is important for the WebDAV group to come up with > a WebDAV spec that defines character encodings for > file names and the relationship of filenames and encodings > to URL strings. Please forgive me if I'm being dense, but isn't this out of the realm of WebDAV? Although there have been some exceptions when people said a given feature was unimplementable, we've usually said that we are only officially concerned with server behaviors that are exposed to and testable/verifyable by a WebDAV client. If we agree that this is still our philosophy, and that the use of files in an implementation is not visible to a client, then perhaps instead of adding it to the base webdav spec, someone should draft an RFC on this apart from WebDAV that documents and resolves this issue. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sun Feb 24 21:33:21 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18943 for ; Sun, 24 Feb 2002 21:33:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA28401; Sun, 24 Feb 2002 18:42:15 -0500 (EST) Resent-Date: Sun, 24 Feb 2002 18:42:15 -0500 (EST) Resent-Message-Id: <200202242342.SAA28401@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 SAA28066 for ; Sun, 24 Feb 2002 18:41:02 -0500 (EST) Received: from hq-exgw2.filenet.com (Filenet-gw.filenet.com [198.3.8.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA12465 for ; Sun, 24 Feb 2002 17:19:48 -0500 Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Feb 2002 14:19:16 -0800 Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3c.org Date: Sun, 24 Feb 2002 14:19:15 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5940 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: Sorry, I misunderstood. I agree with you. Proprietary properites MUST NOT use the DAV: namespace. Alan Babich -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, February 22, 2002 12:49 AM To: Babich, Alan; w3c-dist-auth@w3c.org Subject: RE: Using DAV namespace for proprietary properties Alan, that's fine. My position is that proprietary properties MUST not use the DAV: namespace. If my server can rely on this, it can report all DAV: properties it doesn't know as "not found" without even bothering to ask the persistence layer. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > Sent: Wednesday, February 20, 2002 12:47 AM > To: w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > I don't think it is or should be a requirement that all > proprietary properties be live properties. > > Alan > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, February 18, 2002 11:47 PM > To: Babich, Alan; w3c-dist-auth@w3c.org > Subject: RE: Using DAV namespace for proprietary properties > > > I see. > > Could you please explain this position? > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Babich, Alan > > Sent: Monday, February 18, 2002 9:25 PM > > To: w3c-dist-auth@w3c.org > > Subject: RE: Using DAV namespace for proprietary properties > > > > > > "Would it be permissible to assume that properties in the DAV: namespace > > *never* are dead properties, allowing to skip this step?" > > > > I don't think so. > > > > Alan Babich > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Monday, February 18, 2002 6:29 AM > > To: w3c-dist-auth@w3c.org > > Subject: Using DAV namespace for proprietary properties > > > > > > Hi, > > > > currently RFC2518 is silent on this issue. > > > > However, deltaV says 1.5 [1]: "Although WebDAV request and > response bodies > > can be extended by arbitrary XML elements, which can be ignored by the > > message recipient, an XML element in the DAV namespace MUST NOT > be used in > > the request or response body of a versioning method unless that > > XML element > > is explicitly defined in an IETF RFC." > > > > I think something similar needs to be added to the revision to RFC2518. > > > > Looking at current implementations I notice that the Microsoft Webfolder > > client (sigh!) does a PROPFIND on no less than then 10 proprietary > > properties placed into the DAV: namespace ([2]), of which it > only seems to > > *use* one (DAV:ishidden). Without wiring special knowledge about these > > attributes into a server, it will usually have to consult the resource's > > dead properties (just to find out that these don't exist). Would it be > > permissible to assume that properties in the DAV: namespace > > *never* are dead > > properties, allowing to skip this step? > > > > Julian > > > > > > [1] > > g-20.1.htm > #_Toc524830510> > [2] > From w3c-dist-auth-request@w3.org Mon Feb 25 04:04:14 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02958 for ; Mon, 25 Feb 2002 04:04:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA22498; Mon, 25 Feb 2002 03:58:58 -0500 (EST) Resent-Date: Mon, 25 Feb 2002 03:58:58 -0500 (EST) Resent-Message-Id: <200202250858.DAA22498@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 DAA22473 for ; Mon, 25 Feb 2002 03:58:38 -0500 (EST) 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 DAA05161 for ; Mon, 25 Feb 2002 03:58:37 -0500 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 25 Feb 2002 09:58:18 +0100 Date: Mon, 25 Feb 2002 09:58:21 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: w3c-dist-auth@w3.org To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105E4DA73@SUS-MA1IT01> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: IETF meeting: Refreshing locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5941 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 Am Sonntag den, 24. Februar 2002, um 00:53, schrieb Clemm, Geoff: > The paragraph referred to was in section 9.8: > > The timeout counter SHOULD be restarted any time an owner of > the lock > sends a method to any member of the lock, including unsupported > methods, or methods which are unsuccessful. However the lock > MUST be > refreshed if a refresh LOCK method is successfully received. > > Unfortunately, I cannot remember the rationale for removing this > paragraph, although it might have been that servers aren't actually > doing this in practice? There were several issues in this: 1. unsupported methods might not even be seen by the WebDAV server application (or recognized as WebDAV methods). 2. Refreshing locks on PROPFIND by _any_ client (PROPFIND does not check on If: headers) will give unpredictable timeout behavior. Checking with PROPFIND if a lock is still there has counterproductive side effects. That's the, most likely incomplete, list I remember. //Stefan > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, February 18, 2002 7:01 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: IETF meeting: Refreshing locks > > > > What does the following text from the SLC IETF meaning mean? > >> Refreshing Locks.... >> >> Consensus was to delete paragraph on lock refresh. >> Eric - clients seem to be expecting locks to hang around, when they > expire it causes problems. > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Mon Feb 25 04:29:48 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03324 for ; Mon, 25 Feb 2002 04:29:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA25043; Mon, 25 Feb 2002 04:25:11 -0500 (EST) Resent-Date: Mon, 25 Feb 2002 04:25:11 -0500 (EST) Resent-Message-Id: <200202250925.EAA25043@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 EAA24989 for ; Mon, 25 Feb 2002 04:24:39 -0500 (EST) 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 EAA10630 for ; Mon, 25 Feb 2002 04:24:39 -0500 Received: from burns.greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 25 Feb 2002 10:24:13 +0100 Date: Mon, 25 Feb 2002 10:24:15 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: , "'Jim Whitehead'" , "'WebDAV'" To: "Jason Crawford" From: Stefan Eissing In-Reply-To: Message-Id: <6FC5B09F-29D1-11D6-BF5C-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: [dav-dev] Re: Problem with OfficeXP and Accented characters Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5942 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 Am Sonntag den, 24. Februar 2002, um 23:46, schrieb Jason Crawford: > [...] >> It is important for the WebDAV group to come up with >> a WebDAV spec that defines character encodings for >> file names and the relationship of filenames and encodings >> to URL strings. > > Please forgive me if I'm being dense, but isn't this out of the > realm of > WebDAV? > Although there have been some exceptions when people said a given > feature > was unimplementable, we've usually said that we are only officially > concerned with > server behaviors that are exposed to and testable/verifyable by a > WebDAV > client. If we agree that this is still our philosophy, and that > the use > of files in an > implementation is not visible to a client, then perhaps instead of > adding > it to the base webdav spec, someone should draft an RFC on this > apart from > WebDAV that documents and resolves this issue. There are several aspects: - HTTP needs to define default character encoding for URIs (UTF-8). It would be useful to have a defined way to specify other character encodings (parameter ;charset=xxx ?). Clients need to convert user input/output to/from URIs and currently, I think, this is not well defined. At least RFC 2616 is silent on this issue. - WebDAV should define what the appropriate response is to a PUT/MKCOL with an "invalid" name for the new resurce. "Invalid" in that sense that the server cannot map it to its internal storage or will not permit certain characters. Maybe there should also be a optional Content-Location header in the response, indicating how the server names the new resource, in case this differs from the client (composite characters are one example of why this might be necessary). - WebDAV could define how servers should map "external" names to URIs. An "external" name being for example file names not completely under the servers control or document names from an existing database. //Stefan > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > > From w3c-dist-auth-request@w3.org Mon Feb 25 16:47:38 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01079 for ; Mon, 25 Feb 2002 16:47:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26021; Mon, 25 Feb 2002 16:41:56 -0500 (EST) Resent-Date: Mon, 25 Feb 2002 16:41:56 -0500 (EST) Resent-Message-Id: <200202252141.QAA26021@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 QAA26001 for ; Mon, 25 Feb 2002 16:41:49 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA31698 for ; Mon, 25 Feb 2002 16:41:49 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1PLgpj25448 for ; Mon, 25 Feb 2002 13:42:51 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1PLfb725433 for ; Mon, 25 Feb 2002 13:41:37 -0800 (PST) Received: from localhost ([130.248.188.72]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GS3YWJ00.3SV; Mon, 25 Feb 2002 13:41:07 -0800 Date: Mon, 25 Feb 2002 13:42:03 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Stefan Eissing" , To: "Lisa Dusseault" From: Daniel Brotsky In-Reply-To: Message-Id: <81CFCE43-2A38-11D6-8A37-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5943 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 (Apologies for the late reply; I've been on vacation.) On Saturday, February 16, 2002, at 07:19 PM, Lisa Dusseault wrote: > Application/octet-stream is the generally accepted "don't know what > else to > use" MIME type, the default MIME type. At least if we specify it, > behavior > will definitely be consistent. What's the virtue of not specifying it? I think there are three cases when you lock a URL that has no associated resource: 1. User specifies a Content-type: header on the request. In this case I believe the server SHOULD use that as the mime type of the associated 0-length (newly created) resource. (Interestingly, this is not mandated for a PUT in the spec; see below.) 2. User does not specify a Content-type: header on the request, but the server feels it can guess a mime type from the URL itself (e.g., the URL is /foo.html). In this case the server MAY use the heuristically-determined mime type for the newly created resource. 3. User does not specify a Content-type: header on the request, and the server doesn't feel it can guess a mime type. In this case the server MAY choose to associate application/octet-stream with the resource, but I believe it MAY also choose to associate NO mime type with the resource. In this latter case the server could return a 204 (with no Content-Type: header) to any GET request. > I do agree that when a content-type is included in a PUT overwriting the > empty resource, that should become the new content-type. However isn't > that > always the case, whether the resource was previously empty or not? Interestingly, 2518 says absolutely nothing about this. I personally believe it's a fairly important interoperability issue (since it determines what clients can assume about how servers store their resource). I'd love to see an issue added about it, especially since it would give us a chance to discuss whether the SHOULD in point 1, above, ought to be a MUST. dan From w3c-dist-auth-request@w3.org Mon Feb 25 16:58:07 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01453 for ; Mon, 25 Feb 2002 16:58:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA27449; Mon, 25 Feb 2002 16:54:01 -0500 (EST) Resent-Date: Mon, 25 Feb 2002 16:54:01 -0500 (EST) Resent-Message-Id: <200202252154.QAA27449@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 QAA27324 for ; Mon, 25 Feb 2002 16:53:45 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA00508 for ; Mon, 25 Feb 2002 16:53:45 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1PLpjZ27788 for ; Mon, 25 Feb 2002 13:51:45 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1PLpnY00716 for ; Mon, 25 Feb 2002 13:51:49 -0800 (PST) Received: from localhost ([130.248.188.72]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GS3ZGK00.3TQ; Mon, 25 Feb 2002 13:53:08 -0800 Date: Mon, 25 Feb 2002 13:54:12 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Lisa Dusseault" , To: Stefan Eissing From: Daniel Brotsky In-Reply-To: Message-Id: <340D9C82-2A3A-11D6-8A37-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5944 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 think we're all very interested in the same questions (see my other note in this thread). But I think we need a new issue for it, rather than discussing it as part of the lock-null issue. I think LOCK-based resource creation should work just like PUT-based creation does, and the spec should simply say that. This discussion about PUT and GET behavior should go with PUT. dan On Monday, February 18, 2002, at 02:03 AM, Stefan Eissing wrote: > > Am Sonntag den, 17. Februar 2002, um 04:19, schrieb Lisa Dusseault: > >> >> Stefan Eissing wrote: >>> Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky: >>> >>>> The question: what's the mime-type of the newly-created resource? >>>> >>>> Now I know that many servers use file extensions to determine >>>> mime-type, so the name of the resource could be used to provide a >>>> mime-type. But for other servers that expect clients to supply a >>>> Content-type header on PUT (or at least pay attention to them), >>>> what should happen? >>>> >>>> My proposal: do not mandate behavior around this; leave the spec >>>> silent. That way the spec is silent about mime-type of LOCK >>>> created resources exactly as it's silent about the mime type of >>>> PUT resources. >>> >>> Yesterday we had internally the discussion about the mime-type of >>> a resource with length 0. I think we did not come to a good conclusion >>> and the whole mime-type handling is a mess anyway. >>> >>> The only thing we could agree upon is that a client supplied mime-type >>> on PUT should be persistet (if possible) and override any name >>> extension >>> guesswork. >> >> Application/octet-stream is the generally accepted "don't know what >> else to >> use" MIME type, the default MIME type. At least if we specify it, >> behavior >> will definitely be consistent. What's the virtue of not specifying it? > > Can we specify answers for all questions below? > > 1. When a client creates a resource with "application/octet-stream", > should > the server make a guess and replace octet-stream with another mime type? > > 2. When a client creates a resource without mime type, should > the server make a guess or report application/octet-stream? > > 3. When a server reports application/octet-stream, should a client take > a guess in order to open an application/show an icon? > > 4. When a server reports another mime type, is a client allowed to take > a guess anyway and disregard the server supplied mime type? How does > a client know that the mime type was not "guessed" by the server? > >> I do agree that when a content-type is included in a PUT overwriting >> the >> empty resource, that should become the new content-type. However >> isn't that >> always the case, whether the resource was previously empty or not? > > Yes. The question is more what content-type to report on an empty > resource. > >> Lisa >> > > From w3c-dist-auth-request@w3.org Mon Feb 25 17:07:14 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01678 for ; Mon, 25 Feb 2002 17:07:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28046; Mon, 25 Feb 2002 17:03:01 -0500 (EST) Resent-Date: Mon, 25 Feb 2002 17:03:01 -0500 (EST) Resent-Message-Id: <200202252203.RAA28046@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 RAA28026 for ; Mon, 25 Feb 2002 17:02:55 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA01361 for ; Mon, 25 Feb 2002 17:02:55 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1PM3vj00790 for ; Mon, 25 Feb 2002 14:03:58 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1PM0xY02316 for ; Mon, 25 Feb 2002 14:00:59 -0800 (PST) Received: from localhost ([130.248.188.72]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GS3ZVQ00.5XT; Mon, 25 Feb 2002 14:02:14 -0800 Date: Mon, 25 Feb 2002 14:03:18 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Stefan Eissing" , "Lisa Dusseault" , To: "Julian Reschke" From: Daniel Brotsky In-Reply-To: Message-Id: <79B5A226-2A3B-11D6-8A37-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5945 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 Ah, but there's a real subtlety here. 2616 only gives rules regarding the determination of the MESSAGE's entity body type; it says nothing about what (clients and) servers must do with respect to a RESOURCE that they then store that entity in. That's exactly what we need to specify in 2518's revision. Note that I'm not advocating we should do anything other than the obvious: servers SHOULD always give back the same entity body type they were given for a resource (unless the client says it prefers a different type). But there's a real question in my mind as to whether they MUST do this, and in any event even the SHOULD behavior is nowhere specified. dan On Monday, February 18, 2002, at 04:08 AM, Julian Reschke wrote: >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing >> Sent: Monday, February 18, 2002 11:04 AM >> To: Lisa Dusseault >> Cc: w3c-dist-auth@w3c.org >> Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC >> >> >> >> Am Sonntag den, 17. Februar 2002, um 04:19, schrieb Lisa Dusseault: >> >>> >>> Stefan Eissing wrote: >>>> Am Freitag den, 15. Februar 2002, um 01:57, schrieb Daniel Brotsky: >>>> >>>>> The question: what's the mime-type of the newly-created resource? >>>>> >>>>> Now I know that many servers use file extensions to determine >>>>> mime-type, so the name of the resource could be used to provide a >>>>> mime-type. But for other servers that expect clients to supply a >>>>> Content-type header on PUT (or at least pay attention to them), >>>>> what should happen? >>>>> >>>>> My proposal: do not mandate behavior around this; leave the spec >>>>> silent. That way the spec is silent about mime-type of LOCK >>>>> created resources exactly as it's silent about the mime type of >>>>> PUT resources. >>>> >>>> Yesterday we had internally the discussion about the mime-type of >>>> a resource with length 0. I think we did not come to a good >>>> conclusion >>>> and the whole mime-type handling is a mess anyway. >>>> >>>> The only thing we could agree upon is that a client supplied >>>> mime-type >>>> on PUT should be persistet (if possible) and override any name >>>> extension >>>> guesswork. >>> >>> Application/octet-stream is the generally accepted "don't know >>> what else to >>> use" MIME type, the default MIME type. At least if we specify it, >>> behavior >>> will definitely be consistent. What's the virtue of not specifying >>> it? >> >> Can we specify answers for all questions below? >> >> 1. When a client creates a resource with >> "application/octet-stream", should >> the server make a guess and replace octet-stream with another mime >> type? > > No. As per RFC2616, 7.2.1: If and only if the media type is not given > by a > Content-Type field, the recipient MAY > attempt to guess the media type via inspection of its content and/or the > name extension(s) of the URI used to identify > the resource. If the media type remains unknown, the recipient SHOULD > treat > it as type "application/octetstream". > >> 2. When a client creates a resource without mime type, should >> the server make a guess or report application/octet-stream? > > It could, but I wouldn't recommend that. It may make sense to report a > *specific* content type (such as application/x-foobar), but reporting > "application/octet-stream" doesn't really help anybody. > >> 3. When a server reports application/octet-stream, should a client take >> a guess in order to open an application/show an icon? > > No. See above. > >> 4. When a server reports another mime type, is a client allowed to take >> a guess anyway and disregard the server supplied mime type? How does > > Good question. RFC2616 forbids that. > >> a client know that the mime type was not "guessed" by the server? > > It can't. So it makes sense to let the server only guess if it's > reasonably > sure that it's correct (and useful). > >>> I do agree that when a content-type is included in a PUT >>> overwriting the >>> empty resource, that should become the new content-type. However >>> isn't that >>> always the case, whether the resource was previously empty or not? >> >> Yes. The question is more what content-type to report on an empty >> resource. > > Wether or not a specific content type is valid for an empty resource > depends > on the content type. I don't think that this needs to be treated > different > from non-empty resources. > > Julian > > From w3c-dist-auth-request@w3.org Mon Feb 25 17:08:50 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01714 for ; Mon, 25 Feb 2002 17:08:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28222; Mon, 25 Feb 2002 17:04:36 -0500 (EST) Resent-Date: Mon, 25 Feb 2002 17:04:36 -0500 (EST) Resent-Message-Id: <200202252204.RAA28222@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 RAA28173 for ; Mon, 25 Feb 2002 17:04:29 -0500 (EST) Received: from adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA01531 for ; Mon, 25 Feb 2002 17:04:29 -0500 Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1PM5Vj01171 for ; Mon, 25 Feb 2002 14:05:31 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1PM4F729372 for ; Mon, 25 Feb 2002 14:04:15 -0800 (PST) Received: from localhost ([130.248.188.72]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GS3ZYD00.NWW; Mon, 25 Feb 2002 14:03:49 -0800 Date: Mon, 25 Feb 2002 14:04:53 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: To: "Julian Reschke" From: Daniel Brotsky In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Subject: Re: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5946 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 On Monday, February 18, 2002, at 06:29 AM, Julian Reschke wrote: > Hi, > > currently RFC2518 is silent on this issue. > > However, deltaV says 1.5 [1]: "Although WebDAV request and response > bodies > can be extended by arbitrary XML elements, which can be ignored by the > message recipient, an XML element in the DAV namespace MUST NOT be used > in > the request or response body of a versioning method unless that XML > element > is explicitly defined in an IETF RFC." > > I think something similar needs to be added to the revision to RFC2518. I agree. > > Looking at current implementations I notice that the Microsoft Webfolder > client (sigh!) does a PROPFIND on no less than then 10 proprietary > properties placed into the DAV: namespace ([2]), of which it only seems > to > *use* one (DAV:ishidden). Without wiring special knowledge about these > attributes into a server, it will usually have to consult the resource's > dead properties (just to find out that these don't exist). Would it be > permissible to assume that properties in the DAV: namespace *never* are > dead > properties, allowing to skip this step? I think so. dan > > Julian > > > [1] > versioning-20.1.htm > #_Toc524830510> > [2] > rietary-properties> > From w3c-dist-auth-request@w3.org Tue Feb 26 07:59:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27119 for ; Tue, 26 Feb 2002 07:59:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA25754; Tue, 26 Feb 2002 04:48:14 -0500 (EST) Resent-Date: Tue, 26 Feb 2002 04:48:14 -0500 (EST) Resent-Message-Id: <200202260948.EAA25754@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 EAA25589 for ; Tue, 26 Feb 2002 04:47:48 -0500 (EST) Received: from x-hive.com (www.xhive.com [195.38.217.80]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA09257 for ; Tue, 26 Feb 2002 04:47:48 -0500 Received: from JAKARTA.xhive.archipel (a205160.upc-a.chello.nl [62.163.205.160]) by x-hive.com (8.9.3/8.8.7) with ESMTP id KAA00893 for ; Tue, 26 Feb 2002 10:43:46 +0100 content-class: urn:content-classes:message Date: Tue, 26 Feb 2002 10:47:16 +0100 Message-ID: <41D11F414A26E942912B7E7696DC8E22061591@JAKARTA.xhive.archipel> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Newbie question about LOCK Thread-Index: AcG+qpNLi/35BfefSO24WkwbRf8R+w== X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Sander Bos" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id EAA25589 Subject: Newbie question about LOCK Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5947 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 Hi there, we build a small WebDAV integration for our XML database on top of Tomcat's WebDAV offering. XMetaL 3 is out now, has WebDAV support, but does not cooperate well with the Tomcat WebDAV server. One problem I could figure out myself (for completeness, that was that XMetaL asked a lock for an owner with an XML-fragment like sander, and Tomcat sent back a reply with 'sander' in the response, but without declaring the namespace for 'a'), but I do not know what to do about the second problem I encountered. Since I scrounged off Tomcat's implementation, I am not intimately familiar with the DAV specification. The problem is that the XMetaL client asks for a LOCK on the same resource twice. I included the log at the end of this message, even though there are two different user agents mentioned in the log, for what I know (I'm also new to connection logging) this were actually commands send over one keep-alive connection. Tomcat has sent back a response granting the lock for the first request, then denying the second one since the thing is already locked. I read http://asg.web.cmu.edu/rfc/rfc2518.html#sec-7.8 a couple of times, the first line seems to suggest very clearly that this is illegal for a client to do, all the other lines seem to contradict it a little but are very unclear to me. I do not see any 'If header', but maybe I do not know what to look for. In any event, my question is this: May the client send the requests as it does below, or may it not? Should I find fault with the server or the client? If the fault is with the server, how should it react to the second LOCK-request, should it see that it is from the same user and regrant the lock anyway, and if that is so should it send the same locktoken (just a term I saw while looking for section 7.8) as it did in the first response? (I am sure the people behind XMetaL tested their stuff, so I suppose there must be servers which do grant multiple locks for the same resource?) Kind regards, --Sander. ------ X-Hive Corporation (www.x-hive.com) email: sander@x-hive.com phone: +31 10 7108625 ----------------------------------------------- End of the log of the commands the client send: LOCK /webdav/addresslist1.xml HTTP/1.1 Accept: */* Accept-Language: en-us Content-Type: text/xml Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Host: localhost:8082 Content-Length: 194 Connection: Keep-Alive Cache-Control: no-cache sander GET /webdav/addresslist1.xml HTTP/1.1 Accept: */* User-Agent: DAV Client (C) Host: localhost:8082 Connection: Keep-Alive Cache-Control: no-cache OPTIONS /webdav/addresslist1.xml HTTP/1.1 Accept: */* User-Agent: DAV Client (C) Host: localhost:8082 Content-Length: 0 Connection: Keep-Alive Cache-Control: no-cache LOCK /webdav/addresslist1.xml HTTP/1.1 Accept: */* Accept-Language: en-us Content-Type: text/xml Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Host: localhost:8082 Content-Length: 194 Connection: Keep-Alive Cache-Control: no-cache sander From w3c-dist-auth-request@w3.org Tue Feb 26 12:11:09 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10771 for ; Tue, 26 Feb 2002 12:11:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA01017; Tue, 26 Feb 2002 12:05:10 -0500 (EST) Resent-Date: Tue, 26 Feb 2002 12:05:10 -0500 (EST) Resent-Message-Id: <200202261705.MAA01017@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 MAA00970 for ; Tue, 26 Feb 2002 12:04:49 -0500 (EST) Received: from adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA17682 for ; Tue, 26 Feb 2002 12:04:48 -0500 Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by adobe.com (1.0.0/8.11.4) with ESMTP id g1QH2nB27403 for ; Tue, 26 Feb 2002 09:02:49 -0800 (PST) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g1QH2rY03887 for ; Tue, 26 Feb 2002 09:02:53 -0800 (PST) Received: from localhost ([153.32.159.76]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GS5GQY00.3ZQ; Tue, 26 Feb 2002 09:04:10 -0800 Date: Tue, 26 Feb 2002 08:44:01 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: w3c-dist-auth@w3c.org To: "Jason Crawford" From: Daniel Brotsky In-Reply-To: Message-Id: <094E04E6-2AD8-11D6-8A37-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Subject: Re: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5948 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 yes. dan On Wednesday, February 20, 2002, at 12:29 PM, Jason Crawford wrote: > Do we feel there is a change in the 2518 spec needed in regard to the > following posting by Julian... > > >> currently RFC2518 is silent on this issue. >> >> However, deltaV says 1.5 [1]: "Although WebDAV request and response > bodies >> can be extended by arbitrary XML elements, which can be ignored by the >> message recipient, an XML element in the DAV namespace MUST NOT be used > in >> the request or response body of a versioning method unless that XML > element >> is explicitly defined in an IETF RFC." >> >> I think something similar needs to be added to the revision to RFC2518. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Tue Feb 26 13:20:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14417 for ; Tue, 26 Feb 2002 13:20:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10859; Tue, 26 Feb 2002 13:15:55 -0500 (EST) Resent-Date: Tue, 26 Feb 2002 13:15:55 -0500 (EST) Resent-Message-Id: <200202261815.NAA10859@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 NAA10819 for ; Tue, 26 Feb 2002 13:15:36 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA28920 for ; Tue, 26 Feb 2002 13:15:36 -0500 Received: (qmail 29398 invoked by uid 0); 26 Feb 2002 18:15:04 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp014-rz3) with SMTP; 26 Feb 2002 18:15:04 -0000 From: "Julian Reschke" To: "WebDAV" Date: Tue, 26 Feb 2002 19:15:05 +0100 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.2600.0000 In-Reply-To: Subject: shared locks and IIS, was: Shared locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5949 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 Regarding the interoperabiltiy of shared locks: I've done a few tests and found the following problems with IIS 5.0 (posted here so that it's gets archived and assigned a URL :-): 1) When reporting shared locks, IIS inserts one DAV:lockdiscovery element for *each* shared lock into the DAV:prop element. This is plain wrong, because each DAV: property can only have a single value (maybe the spec should clarify this in an example?). 2) When UNLOCKing shared locks, it seems that IIS sometimes removes the wrong lock (you have lock tokens "a", "b" and "c", remove "a", and upon a new PROPFIND, "a" and "b" are reported). Shared locks in moddav seem to work as expected (as far as my own tests are concerned). Julian From w3c-dist-auth-request@w3.org Wed Feb 27 00:43:29 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03524 for ; Wed, 27 Feb 2002 00:43:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA03238; Wed, 27 Feb 2002 00:42:29 -0500 (EST) Resent-Date: Wed, 27 Feb 2002 00:42:29 -0500 (EST) Resent-Message-Id: <200202270542.AAA03238@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 AAA03218 for ; Wed, 27 Feb 2002 00:42:22 -0500 (EST) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA00747 for ; Wed, 27 Feb 2002 00:42:22 -0500 Received: from Tycho (dsl3-63-249-67-115.cruzio.com [63.249.67.115]) by mail.cruzio.com with SMTP id VAA03665 for ; Tue, 26 Feb 2002 21:42:36 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 26 Feb 2002 21:42:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: WG: Features of WEBDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5950 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 Accidentally caught by the spam filter. - Jim -----Original Message----- From: Philipp Schreiber [mailto:schreiber@massive.de] Sent: Monday, February 25, 2002 4:36 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WG: Features of WEBDAV -----Ursprüngliche Nachricht----- Von: Philipp Schreiber [mailto:schreiber@massive.de] Gesendet: Montag, 25. Februar 2002 13:13 An: 'gstein@lyra.org' Betreff: Features of WEBDAV Hallo, In your FAQ's on webdav.org I found the question "Which features are complete, etc". In your answer you write about "Versioning and Configuration Management" that this work "...is expected to be complete in late 2000". Now we have Feb 2002 and I cannot find any information about the state of development. Can you give me some information about the state of development of "Advanced Collections", "Versioning and Configuration Management" and "Access Control"? Thank you. With greetings from Germany, Philipp Schreiber ____________________________________ Philipp Schreiber, Level Designer phone : +49 (621) 33 864 21 fax : +49 (621) 33 864 29 mailto:schreiber@massive.de Massive Development GmbH Joseph-Meyer-Str. 13-15 68167 Mannheim / Germany http://www.massive.de/ From w3c-dist-auth-request@w3.org Wed Feb 27 00:49:40 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03590 for ; Wed, 27 Feb 2002 00:49:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA03655; Wed, 27 Feb 2002 00:48:41 -0500 (EST) Resent-Date: Wed, 27 Feb 2002 00:48:41 -0500 (EST) Resent-Message-Id: <200202270548.AAA03655@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 AAA03622 for ; Wed, 27 Feb 2002 00:48:34 -0500 (EST) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA01310 for ; Wed, 27 Feb 2002 00:48:34 -0500 Received: from Tycho (dsl3-63-249-67-115.cruzio.com [63.249.67.115]) by mail.cruzio.com with SMTP id VAA07970 for ; Tue, 26 Feb 2002 21:48:55 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 26 Feb 2002 21:48:55 -0800 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: WG Meeting at Minneapolis IETF 53 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5951 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 A meeting of the WebDAV Working Group is scheduled for the Minneapolis IETF meeting. Information on registering for the meeting, along with hotel information, can be found at: http://www.ietf.org/meetings/IETF-53.html The WebDAV WG meeting is currently scheduled for Tuesday, March 19, 2002, from 9AM to 11:30AM. Of the two co-chairs, Lisa Dusseault will be attending and leading the meeting; I will not be able to attend. While the final agenda for the meeting has not yet been worked out, I suspect it will involve some discussion on ACL issues (based on the implementation feedback we've been receiving), and discussion of open issues in RFC 2518, and Lisa's RFC 2518bis draft. If you have other business you'd like discussed at the meeting, please email Lisa and I. - Jim From w3c-dist-auth-request@w3.org Wed Feb 27 01:04:38 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03758 for ; Wed, 27 Feb 2002 01:04:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA04662; Wed, 27 Feb 2002 01:03:47 -0500 (EST) Resent-Date: Wed, 27 Feb 2002 01:03:47 -0500 (EST) Resent-Message-Id: <200202270603.BAA04662@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 BAA04634 for ; Wed, 27 Feb 2002 01:03:23 -0500 (EST) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA02851 for ; Wed, 27 Feb 2002 01:03:23 -0500 Received: from Tycho (dsl3-63-249-67-115.cruzio.com [63.249.67.115]) by mail.cruzio.com with SMTP id WAA18366; Tue, 26 Feb 2002 22:03:44 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Cc: Date: Tue, 26 Feb 2002 22:03:43 -0800 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: Features of WEBDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5953 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 Philipp, Good questions -- it has been awhile since a status report has been made to the WebDAV WG. In brief: DeltaV specification: it has been approved by the IESG, and is awaiting publication as an RFC. I expect this to happen sometime in March -- I'm a bit surprised the RFC hasn't been issued yet, but it is rather long. Access control specification: it has passed a WG last call for comments, but several substantive pieces of feedback have been received since this time. There will be at least one more draft of the ACL specification, and at least one more WG last call, before it is sent along for approval by the IESG. This will probably be completed sometime in early summer 2002. Advanced collections work is currently on hold. After ACLs, the next major piece of work will be completing the DASL specification. DASL is looking like it will be finished in late 2002. Hope this helps, - Jim > In your FAQ's on webdav.org I found the question "Which features are > complete, etc". In your answer you write about "Versioning and > Configuration Management" that this work "...is expected to be complete > in late 2000". Now we have Feb 2002 and I cannot find any information > about the state of development. Can you give me some information about > the state of development of "Advanced Collections", "Versioning and > Configuration Management" and "Access Control"? > > Thank you. > > With greetings from Germany, > > Philipp Schreiber > > ____________________________________ > Philipp Schreiber, Level Designer > phone : +49 (621) 33 864 21 > fax : +49 (621) 33 864 29 > mailto:schreiber@massive.de > > Massive Development GmbH > Joseph-Meyer-Str. 13-15 > 68167 Mannheim / Germany > http://www.massive.de/ > From w3c-dist-auth-request@w3.org Wed Feb 27 01:57:45 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03584 for ; Wed, 27 Feb 2002 00:49:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA03691; Wed, 27 Feb 2002 00:48:49 -0500 (EST) Resent-Date: Wed, 27 Feb 2002 00:48:49 -0500 (EST) Resent-Message-Id: <200202270548.AAA03691@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 AAA03633 for ; Wed, 27 Feb 2002 00:48:35 -0500 (EST) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA01312 for ; Wed, 27 Feb 2002 00:48:35 -0500 Received: from Tycho (dsl3-63-249-67-115.cruzio.com [63.249.67.115]) by mail.cruzio.com with SMTP id VAA07996 for ; Tue, 26 Feb 2002 21:48:56 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 26 Feb 2002 21:48:55 -0800 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: RE: Windows XP Webdav redirector Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5952 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: Brian Olore [mailto:bolore@us.ibm.com] Sent: Monday, February 25, 2002 8:36 AM To: w3c-dist-auth@w3.org; julian.reschke@hmx.de Subject: [Moderator Action] RE: Windows XP Webdav redirector Hi Julian ... I am not sure if you have tried, but I am not able to "net use" a URI that uses https://. If I use http:// to the same server, it works fine, but since I am transmitting id/pw, I need the SSL. I have scoured the groups and MS's site and cannot find anything useful. It seems as if we are the only ones dealing with MS's mess. Any recommendations would be appreciated. Thanks, Brian bolore@us.ibm.com From: "Julian Reschke" To: "Julian Reschke" , Date: Tue, 15 Jan 2002 17:16:56 +0100 Message-ID: Subject: RE: Windows XP Webdav redirector OK, we finally fingured out the WebDAV redirector was refusing to connect: it *requires* that XML elements in the DAV: namespace use a prefix. This means, it won't recognize while will work. Sigh. It would be really great if Microsoft would start fixing the WebDAV support in their clients and servers. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, January 14, 2002 7:34 PM > To: w3c-dist-auth@w3c.org > Subject: Windows XP Webdav redirector > > > Hi, > > I've been trying to get the WebDAV "redirector" (UA > WebDAV-MiniRedir/5.1.2600) in Windows XP to mount our WebDAV > server. I've found three issues for which I have workarounds, > however, I'm > still not able > to mount from my server. > > Problem #1: basic authentication seems to be broken if the > redirector *prompts* for the credentials. If you supply them on the > command line: > > "net use * URI password /user:username" > > it seems to work. > > Problem #2: given a URI like "http://server/a/b/c", the client > tries OPTIONS > and PROPFIND on "http://server/a" (which is wrong because this > resource may > not be WebDAV enabled). A similar (known!) problem exists in IE's > "open as web folder", while mounting a web folder using network > places behaves correctly. > > Problem #3: the URI may not contain a port number (even if it's > 80!) > > All these problems lead to error message 67 ("network name not > found") with > absolutely no useful additional information. > > > After working around these issues, I can get the redirector to > issue a PROPFIND (Depth: 0) against by target URI (with correct > Basic > Authentication > credentials), and my server is responding with 207 (MULTISTATUS) > and a response body which seems to be just fine (and is accepted by > the > webfolder > client). However, I'm still getting error #67. > > Did anybody else have a similar problem and knows what might be > going wrong? > > Julian From w3c-dist-auth-request@w3.org Wed Feb 27 17:31:00 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22484 for ; Wed, 27 Feb 2002 17:30:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA04448; Wed, 27 Feb 2002 17:26:29 -0500 (EST) Resent-Date: Wed, 27 Feb 2002 17:26:29 -0500 (EST) Resent-Message-Id: <200202272226.RAA04448@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 RAA04420 for ; Wed, 27 Feb 2002 17:26:15 -0500 (EST) 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 RAA29653 for ; Wed, 27 Feb 2002 17:26:15 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA343440 for ; Wed, 27 Feb 2002 17:22:26 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1RMPcd65028 for ; Wed, 27 Feb 2002 17:25:38 -0500 To: "WebDAV" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 27 Feb 2002 17:25:15 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/27/2002 05:25:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Issue: DUPLICATE_PROPERTIES Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5954 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, > 1) When reporting shared locks, IIS inserts one DAV:lockdiscovery element > for *each* shared lock into the DAV:prop element. This is plain wrong, > because each DAV: property can only have a single value (maybe the spec > should clarify this in an example?). I've entered this as an issue. And noted that the spec should be changed to say that a resource should only have one property with a given name. If you think this is too obvious to put in the spec or if you have some other problem with this solution, please speak up. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Feb 27 18:03:03 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23445 for ; Wed, 27 Feb 2002 18:03:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA10141; Wed, 27 Feb 2002 18:02:15 -0500 (EST) Resent-Date: Wed, 27 Feb 2002 18:02:15 -0500 (EST) Resent-Message-Id: <200202272302.SAA10141@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 SAA10114 for ; Wed, 27 Feb 2002 18:02:07 -0500 (EST) 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 SAA01966 for ; Wed, 27 Feb 2002 18:02:07 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA08660 for ; Wed, 27 Feb 2002 17:58:21 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1RN1Xd147430 for ; Wed, 27 Feb 2002 18:01:33 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Wed, 27 Feb 2002 17:57:49 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/27/2002 06:01:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Using DAV namespace for proprietary properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5955 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 created an issue DAV_XML_NAMESPACE_IS_RESERVED. It says we have consensus on this issue. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Feb 28 01:04:17 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04782 for ; Thu, 28 Feb 2002 01:04:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA11538; Thu, 28 Feb 2002 01:03:17 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 01:03:17 -0500 (EST) Resent-Message-Id: <200202280603.BAA11538@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 BAA11506 for ; Thu, 28 Feb 2002 01:03:03 -0500 (EST) Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA17197 for ; Thu, 28 Feb 2002 01:03:03 -0500 Received: from dialup-209.247.247.73.dial1.sanfrancisco1.level3.net ([209.247.247.73] helo=[10.0.1.5]) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16gJeZ-0002FC-00 for w3c-dist-auth@w3c.org; Wed, 27 Feb 2002 22:02:55 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: Date: Wed, 27 Feb 2002 21:58:50 -0800 To: w3c-dist-auth@w3c.org From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5956 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 been reading the archives, and following the long-running and sometimes contentious conversation over retrieval of source documents. Maybe bringing this up will get me kicked off the list, but we'll see. First, I appreciate what the DAV working group is trying to do by allowing multiple sources for a given document, and making each source a separate resource. I won't bother denying that it is useful to some people and interesting in its own right. I totally see the logic in it. But it is an abstraction that is useful only to a small minority of users, and is very difficult to implement. If you doubt that, I direct you to the total lack of implementations. But I'll make a case on other grounds, as well. With any DAV request except GET the process is rather straightforward: A virtual host is selected Security determines what rights the user has on the URL. In the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our universe (WebSTAR) that means read, write, list, mkdir, etc.. We figure out what file the URL maps to. In deciding which plug-in will handle the request, a DAV plug-in simply claims anything with a DAV-specific method. If it is MKCOL, DELETE, etc. then the DAV plug-in claims it. DAV handles the request, within the limits set by the security plug-in. All of this works great, until we get to the GET method. Plug-ins have no way of knowing the difference between a normal GET that should be handled normally, and a GET that is intended to retrieve the source of a document and requires special permissions. In effect we have TWO semantics for GET. And so we start creating fake URL spaces. But we quickly run into security and configuration hassles. The bottom line is that there's no way to provide good DAV access without some special configuration on the server. And it isn't the result of some kind of design error by the implementor, but a basic issue with how the protocol is designed. Unless you are only dealing with static content you MUST set up a whole new URL space to do DAV at all. In practice setting this up is such a bother that what most administrators do is create a whole new virtual host with all plug-ins disabled in order to get it done. Is it just me, or is it entirely ridiculous that server administrators have to double the number of virtual hosts they support just to give decent DAV access to their users? And all of this is so complicated for something that *should* be really simple! From most servers' point of view DAV is a way to let web authors access their .php, .cgi, .ssi, .shtml, and other dynamic files and edit them and save them back onto the server. All of this business about an arbitrary number of sources of arbitrary types as properties of a single resource don't do our users one bit of good, but the implementation is quite burdensome. What we really need from the DAV protocol is a way to know that a given request is intended to retrieve the source of a document, without having to also posses knowledge about the DAV configuration, or which URL spaces have been quarantined for use exclusively for WebDAV, and without having to create special areas in the URL space that don't actually map to anything else in the universe just so we can turn off all the plug-ins for a few requests. Thus the suggestion for a GETSRC property. I've read the arguments that ask about FINDPROP and other methods that act on a resource, and having to double the number of methods to support FINDPROP and FINDPROPSRC, etc.. But in most server implementations when you get the properties of a .php or .ssi file right now, what are you getting? In practice you're getting the author and lastmod date and other information about the SOURCE, not the output. I don't know of anybody who is executing a .php file and then returning the properties of the output -- it (a) isn't practical because of all the side-effects it would cause like CPU load and errors and code running that you didn't really intend to run and (b) isn't useful because nobody cares one whit about the DAV properties of PHP output. I suggest that we just stop considering GET to be a DAV method at all. GET has nothing to do with DAV any more than POST does. Instead of GET, we should be using GETSRC (or whatever you want to call it), always. If you want the output of a source which has been run through PHP or SSI or whatever, then fire up your web browser and use a GET or POST method. Otherwise, use your DAV client and GETSRC (or whatever). When you work with the properties of a resource, you are working with the properties of the resource you receive from a GETSRC command. When you GETSRC, you receive the same data that you PUT. When you GET or POST, you receive what the server generates from the source and your input. In some cases that happens to be the same as the source (static files). If OPTIONS does not indicate that GETSRC is avialable, then a DAV client may use GET instead. Does not preclude a document from having multiple sources at different URIs, for the 5% of implementations that need such functionality. Advantages of this approach: Works well with existing security modules for Apache and other servers. Just add GETSRC to the list of methods a user is allowed to use. Provides one semantic for GET (the existing semantic from HTTP/1.1 spec) and only one semantic. Is far more likely to be implemented, and implemented WIDELY, than the src property ever will be. This is a major, major problem with the protocol. This is in not an indictment of anybody's abilities. Even as a prospective implementor reading the spec carefully I didn't appreciate the magnitude of the problem until I set out to really implement it, and then it became nearly intractable. Even the reference implementation doesn't implement it. The DAV group can take this issue in hand and come up with a solution people are willing to implement, or the ad-hoc solutions will become de-facto standards. (ie: Translate). Personally, I would rather see this solved by the DAV working group. cjh -- From w3c-dist-auth-request@w3.org Thu Feb 28 01:20:06 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04955 for ; Thu, 28 Feb 2002 01:20:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA12223; Thu, 28 Feb 2002 01:19:20 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 01:19:20 -0500 (EST) Resent-Message-Id: <200202280619.BAA12223@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 BAA12203 for ; Thu, 28 Feb 2002 01:19:08 -0500 (EST) 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 BAA18499 for ; Thu, 28 Feb 2002 01:19:08 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1S6IvG11442 for ; Wed, 27 Feb 2002 22:18:57 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g1S6IuI24609 for ; Wed, 27 Feb 2002 23:18:56 -0700 (MST) From: "Eric Sedlar" To: Date: Wed, 27 Feb 2002 22:18:51 -0800 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5957 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 Actually, I think Lisa & I convinced Geoff (the big holdout against the Translate header) to give in at the last IETF meeting. Are there any other holdouts with good reason to have a problem with the translate header? --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > Sent: Wednesday, February 27, 2002 9:59 PM > To: w3c-dist-auth@w3c.org > Subject: A case for GETSRC (or other mechanism to that effect) > > > I've been reading the archives, and following the long-running and > sometimes contentious conversation over retrieval of source > documents. Maybe bringing this up will get me kicked off the list, > but we'll see. > > First, I appreciate what the DAV working group is trying to do by > allowing multiple sources for a given document, and making each > source a separate resource. I won't bother denying that it is useful > to some people and interesting in its own right. I totally see the > logic in it. But it is an abstraction that is useful only to a small > minority of users, and is very difficult to implement. If you doubt > that, I direct you to the total lack of implementations. But I'll > make a case on other grounds, as well. > > With any DAV request except GET the process is rather straightforward: > > A virtual host is selected > > Security determines what rights the user has on the URL. In > the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our > universe (WebSTAR) that means read, write, list, mkdir, etc.. > > We figure out what file the URL maps to. > > In deciding which plug-in will handle the request, a DAV > plug-in simply claims anything with a DAV-specific method. If it is > MKCOL, DELETE, etc. then the DAV plug-in claims it. > > DAV handles the request, within the limits set by the > security plug-in. > > All of this works great, until we get to the GET method. Plug-ins > have no way of knowing the difference between a normal GET that > should be handled normally, and a GET that is intended to retrieve > the source of a document and requires special permissions. In effect > we have TWO semantics for GET. And so we start creating fake URL > spaces. But we quickly run into security and configuration hassles. > > The bottom line is that there's no way to provide good DAV access > without some special configuration on the server. And it isn't the > result of some kind of design error by the implementor, but a basic > issue with how the protocol is designed. Unless you are only dealing > with static content you MUST set up a whole new URL space to do DAV > at all. > > In practice setting this up is such a bother that what most > administrators do is create a whole new virtual host with all > plug-ins disabled in order to get it done. Is it just me, or is it > entirely ridiculous that server administrators have to double the > number of virtual hosts they support just to give decent DAV access > to their users? > > And all of this is so complicated for something that *should* be > really simple! From most servers' point of view DAV is a way to let > web authors access their .php, .cgi, .ssi, .shtml, and other dynamic > files and edit them and save them back onto the server. All of this > business about an arbitrary number of sources of arbitrary types as > properties of a single resource don't do our users one bit of good, > but the implementation is quite burdensome. > > What we really need from the DAV protocol is a way to know that a > given request is intended to retrieve the source of a document, > without having to also posses knowledge about the DAV configuration, > or which URL spaces have been quarantined for use exclusively for > WebDAV, and without having to create special areas in the URL space > that don't actually map to anything else in the universe just so we > can turn off all the plug-ins for a few requests. Thus the > suggestion for a GETSRC property. > > I've read the arguments that ask about FINDPROP and other methods > that act on a resource, and having to double the number of methods to > support FINDPROP and FINDPROPSRC, etc.. But in most server > implementations when you get the properties of a .php or .ssi file > right now, what are you getting? In practice you're getting the > author and lastmod date and other information about the SOURCE, not > the output. I don't know of anybody who is executing a .php file and > then returning the properties of the output -- it (a) isn't practical > because of all the side-effects it would cause like CPU load and > errors and code running that you didn't really intend to run and (b) > isn't useful because nobody cares one whit about the DAV properties > of PHP output. > > I suggest that we just stop considering GET to be a DAV method at > all. GET has nothing to do with DAV any more than POST does. > Instead of GET, we should be using GETSRC (or whatever you want to > call it), always. If you want the output of a source which has been > run through PHP or SSI or whatever, then fire up your web browser and > use a GET or POST method. Otherwise, use your DAV client and GETSRC > (or whatever). > > When you work with the properties of a resource, you are working with > the properties of the resource you receive from a GETSRC command. > When you GETSRC, you receive the same data that you PUT. When you > GET or POST, you receive what the server generates from the source > and your input. In some cases that happens to be the same as the > source (static files). > > > If OPTIONS does not indicate that GETSRC is avialable, then a DAV > client may use GET instead. > > Does not preclude a document from having multiple sources at > different URIs, for the 5% of implementations that need such > functionality. > > Advantages of this approach: > > Works well with existing security modules for Apache and > other servers. Just add GETSRC to the list of methods a user is > allowed to use. > > Provides one semantic for GET (the existing semantic from > HTTP/1.1 spec) and only one semantic. > > Is far more likely to be implemented, and implemented WIDELY, > than the src property ever will be. > > > This is a major, major problem with the protocol. This is in not an > indictment of anybody's abilities. Even as a prospective implementor > reading the spec carefully I didn't appreciate the magnitude of the > problem until I set out to really implement it, and then it became > nearly intractable. Even the reference implementation doesn't > implement it. > > The DAV group can take this issue in hand and come up with a solution > people are willing to implement, or the ad-hoc solutions will become > de-facto standards. (ie: Translate). Personally, I would rather see > this solved by the DAV working group. > > > cjh > > -- > > From w3c-dist-auth-request@w3.org Thu Feb 28 04:08:33 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14938 for ; Thu, 28 Feb 2002 04:08:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA22342; Thu, 28 Feb 2002 04:07:26 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 04:07:26 -0500 (EST) Resent-Message-Id: <200202280907.EAA22342@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 EAA22284 for ; Thu, 28 Feb 2002 04:07:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA07177 for ; Thu, 28 Feb 2002 04:07:06 -0500 Received: (qmail 1616 invoked by uid 0); 28 Feb 2002 09:06:30 -0000 Received: from p50825ec2.dip.t-dialin.net (HELO lisa) (80.130.94.194) by mail.gmx.net (mp005-rz3) with SMTP; 28 Feb 2002 09:06:30 -0000 From: "Julian Reschke" To: "Eric Sedlar" , Date: Thu, 28 Feb 2002 10:06:24 +0100 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 V6.00.2600.0000 Importance: Normal Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5958 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 Eric, that comes as a suprise. As far as I remember the discussion we concluced that: a) the Translate header (or GETSRC) solves only a very specific part of the problem (when there's a one-to-one mapping between source and output), b) the source property needs additional work to become usable, but it's a more generic solution. So as far as I am concerned, the plan was to fix the source property (maybe be taking it out of RFC2518bis and to fix it in a sperate draft). If there were out-of-band discussions, I'd certainly like to hear about it. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Thursday, February 28, 2002 7:19 AM > To: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > Actually, I think Lisa & I convinced Geoff (the big holdout against the > Translate header) to give in at the last IETF meeting. Are there > any other > holdouts with good reason to have a problem with the translate header? > > --Eric > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > > Sent: Wednesday, February 27, 2002 9:59 PM > > To: w3c-dist-auth@w3c.org > > Subject: A case for GETSRC (or other mechanism to that effect) > > > > > > I've been reading the archives, and following the long-running and > > sometimes contentious conversation over retrieval of source > > documents. Maybe bringing this up will get me kicked off the list, > > but we'll see. > > > > First, I appreciate what the DAV working group is trying to do by > > allowing multiple sources for a given document, and making each > > source a separate resource. I won't bother denying that it is useful > > to some people and interesting in its own right. I totally see the > > logic in it. But it is an abstraction that is useful only to a small > > minority of users, and is very difficult to implement. If you doubt > > that, I direct you to the total lack of implementations. But I'll > > make a case on other grounds, as well. > > > > With any DAV request except GET the process is rather straightforward: > > > > A virtual host is selected > > > > Security determines what rights the user has on the URL. In > > the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our > > universe (WebSTAR) that means read, write, list, mkdir, etc.. > > > > We figure out what file the URL maps to. > > > > In deciding which plug-in will handle the request, a DAV > > plug-in simply claims anything with a DAV-specific method. If it is > > MKCOL, DELETE, etc. then the DAV plug-in claims it. > > > > DAV handles the request, within the limits set by the > > security plug-in. > > > > All of this works great, until we get to the GET method. Plug-ins > > have no way of knowing the difference between a normal GET that > > should be handled normally, and a GET that is intended to retrieve > > the source of a document and requires special permissions. In effect > > we have TWO semantics for GET. And so we start creating fake URL > > spaces. But we quickly run into security and configuration hassles. > > > > The bottom line is that there's no way to provide good DAV access > > without some special configuration on the server. And it isn't the > > result of some kind of design error by the implementor, but a basic > > issue with how the protocol is designed. Unless you are only dealing > > with static content you MUST set up a whole new URL space to do DAV > > at all. > > > > In practice setting this up is such a bother that what most > > administrators do is create a whole new virtual host with all > > plug-ins disabled in order to get it done. Is it just me, or is it > > entirely ridiculous that server administrators have to double the > > number of virtual hosts they support just to give decent DAV access > > to their users? > > > > And all of this is so complicated for something that *should* be > > really simple! From most servers' point of view DAV is a way to let > > web authors access their .php, .cgi, .ssi, .shtml, and other dynamic > > files and edit them and save them back onto the server. All of this > > business about an arbitrary number of sources of arbitrary types as > > properties of a single resource don't do our users one bit of good, > > but the implementation is quite burdensome. > > > > What we really need from the DAV protocol is a way to know that a > > given request is intended to retrieve the source of a document, > > without having to also posses knowledge about the DAV configuration, > > or which URL spaces have been quarantined for use exclusively for > > WebDAV, and without having to create special areas in the URL space > > that don't actually map to anything else in the universe just so we > > can turn off all the plug-ins for a few requests. Thus the > > suggestion for a GETSRC property. > > > > I've read the arguments that ask about FINDPROP and other methods > > that act on a resource, and having to double the number of methods to > > support FINDPROP and FINDPROPSRC, etc.. But in most server > > implementations when you get the properties of a .php or .ssi file > > right now, what are you getting? In practice you're getting the > > author and lastmod date and other information about the SOURCE, not > > the output. I don't know of anybody who is executing a .php file and > > then returning the properties of the output -- it (a) isn't practical > > because of all the side-effects it would cause like CPU load and > > errors and code running that you didn't really intend to run and (b) > > isn't useful because nobody cares one whit about the DAV properties > > of PHP output. > > > > I suggest that we just stop considering GET to be a DAV method at > > all. GET has nothing to do with DAV any more than POST does. > > Instead of GET, we should be using GETSRC (or whatever you want to > > call it), always. If you want the output of a source which has been > > run through PHP or SSI or whatever, then fire up your web browser and > > use a GET or POST method. Otherwise, use your DAV client and GETSRC > > (or whatever). > > > > When you work with the properties of a resource, you are working with > > the properties of the resource you receive from a GETSRC command. > > When you GETSRC, you receive the same data that you PUT. When you > > GET or POST, you receive what the server generates from the source > > and your input. In some cases that happens to be the same as the > > source (static files). > > > > > > If OPTIONS does not indicate that GETSRC is avialable, then a DAV > > client may use GET instead. > > > > Does not preclude a document from having multiple sources at > > different URIs, for the 5% of implementations that need such > > functionality. > > > > Advantages of this approach: > > > > Works well with existing security modules for Apache and > > other servers. Just add GETSRC to the list of methods a user is > > allowed to use. > > > > Provides one semantic for GET (the existing semantic from > > HTTP/1.1 spec) and only one semantic. > > > > Is far more likely to be implemented, and implemented WIDELY, > > than the src property ever will be. > > > > > > This is a major, major problem with the protocol. This is in not an > > indictment of anybody's abilities. Even as a prospective implementor > > reading the spec carefully I didn't appreciate the magnitude of the > > problem until I set out to really implement it, and then it became > > nearly intractable. Even the reference implementation doesn't > > implement it. > > > > The DAV group can take this issue in hand and come up with a solution > > people are willing to implement, or the ad-hoc solutions will become > > de-facto standards. (ie: Translate). Personally, I would rather see > > this solved by the DAV working group. > > > > > > cjh > > > > -- > > > > > From w3c-dist-auth-request@w3.org Thu Feb 28 04:18:41 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15223 for ; Thu, 28 Feb 2002 04:18:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA23274; Thu, 28 Feb 2002 04:17:54 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 04:17:54 -0500 (EST) Resent-Message-Id: <200202280917.EAA23274@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 EAA23222 for ; Thu, 28 Feb 2002 04:17:24 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA09053 for ; Thu, 28 Feb 2002 04:17:24 -0500 Received: (qmail 29693 invoked by uid 0); 28 Feb 2002 09:16:52 -0000 Received: from p50825ec2.dip.t-dialin.net (HELO lisa) (80.130.94.194) by mail.gmx.net (mp009-rz3) with SMTP; 28 Feb 2002 09:16:52 -0000 From: "Julian Reschke" To: "CJ Holmes" , Date: Thu, 28 Feb 2002 10:16:47 +0100 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5959 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 CJ Holmes > Sent: Thursday, February 28, 2002 6:59 AM > To: w3c-dist-auth@w3c.org > Subject: A case for GETSRC (or other mechanism to that effect) > > ... > > First, I appreciate what the DAV working group is trying to do by > allowing multiple sources for a given document, and making each > source a separate resource. I won't bother denying that it is useful > to some people and interesting in its own right. I totally see the > logic in it. But it is an abstraction that is useful only to a small > minority of users, and is very difficult to implement. If you doubt > that, I direct you to the total lack of implementations. But I'll I think the lack of implementations is caused by - people choose to support the Translate header because they really haven't a choice (as this is what the Microsoft clients use), - the description of the source property is buggy and hard to understand (this could be fixed). > make a case on other grounds, as well. > > With any DAV request except GET the process is rather straightforward: > > A virtual host is selected > > Security determines what rights the user has on the URL. In > the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our > universe (WebSTAR) that means read, write, list, mkdir, etc.. > > We figure out what file the URL maps to. > > In deciding which plug-in will handle the request, a DAV > plug-in simply claims anything with a DAV-specific method. If it is > MKCOL, DELETE, etc. then the DAV plug-in claims it. > > DAV handles the request, within the limits set by the > security plug-in. > > All of this works great, until we get to the GET method. Plug-ins > have no way of knowing the difference between a normal GET that > should be handled normally, and a GET that is intended to retrieve > the source of a document and requires special permissions. In effect > we have TWO semantics for GET. And so we start creating fake URL > spaces. But we quickly run into security and configuration hassles. I object to the term "fake URL space". Defining separate namespaces for sources and outputs seems like a logical solution to me. > The bottom line is that there's no way to provide good DAV access > without some special configuration on the server. And it isn't the > result of some kind of design error by the implementor, but a basic > issue with how the protocol is designed. Unless you are only dealing > with static content you MUST set up a whole new URL space to do DAV > at all. Yes. So? I don't understand why this is a problem per se. > In practice setting this up is such a bother that what most > administrators do is create a whole new virtual host with all > plug-ins disabled in order to get it done. Is it just me, or is it > entirely ridiculous that server administrators have to double the > number of virtual hosts they support just to give decent DAV access > to their users? Well, they don't. How this is done is completely implementation-specific, I'd say. > ... I think we need to answer this questions. Given an ASP file and it's output -- are these two different resources, or are they different representations of the same resource? In the first case they'll *need* different URIs, in the other case normal HTTP variant handling can be used. Even when you choose the latter -- how do you treat then output resources with multiple source resources? From w3c-dist-auth-request@w3.org Thu Feb 28 04:26:31 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15323 for ; Thu, 28 Feb 2002 04:26:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA23905; Thu, 28 Feb 2002 04:25:31 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 04:25:31 -0500 (EST) Resent-Message-Id: <200202280925.EAA23905@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 EAA23884 for ; Thu, 28 Feb 2002 04:25:07 -0500 (EST) Received: from rgminet1.oracle.com (rgminet1.oracle.com [148.87.122.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA10497 for ; Thu, 28 Feb 2002 04:25:06 -0500 Received: from rgmgw4.us.oracle.com (rgmgw4.us.oracle.com [138.1.191.13]) by rgminet1.oracle.com (Switch-2.1.4/Switch-2.1.0) with ESMTP id g1S9STV17075; Thu, 28 Feb 2002 02:28:29 -0700 (MST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw4.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g1S9P4M14942; Thu, 28 Feb 2002 02:25:04 -0700 (MST) From: "Eric Sedlar" To: "Julian Reschke" , Date: Thu, 28 Feb 2002 01:24:58 -0800 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5960 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 think the point is that for every method other than GET, the method operates on a particular source object, not a set of them. dav:source is actually trying to track one level beyond that. Translate: F, or GETSRC, is just trying to get back the same contents that were PUT to that location. The only time Translate/GETSRC is relevant is for executables (cgi's, servlets, etc.) at a particular URL which generate some dynamic content. So, there are really three different sets of content we are looking at: 1) the generated output returned by GET 2) the executable that generates the content for GET, and which is the object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK, MOVE, COPY, ...) 3) the multiple source files that were used to generate the executable The GET method returns resource #1, dav:source (if it were actually implemented by anyone) would list #3. Translate: F, or GETSRC, returns resource #2, which is the one logically consistent with the other WebDAV methods. Actually figuring out #3 is something the equivalent of makefile dependency tracking, and is not generally available even in a development environment, which is something that WebDAV is certainly not. Real-world experience has shown that: * nobody actually tracks multiple source files for an executable * people sometimes want to actually get the executable contents Nobody has actually come up with a real-world use-case for dav:source, but whether or not dav:source is deprecated or not, it's actually identifying a different set of content than Translate: F / GETSRC. And, once you realize that you need Translate: F or GETSRC, you might as well use Translate: F, as you will have no problem getting interoperable implementations, and it is functionally equivalent to GETSRC. --Eric > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, February 28, 2002 1:06 AM > To: Eric Sedlar; w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > Eric, > > that comes as a suprise. > > As far as I remember the discussion we concluced that: > > a) the Translate header (or GETSRC) solves only a very specific > part of the > problem (when there's a one-to-one mapping between source and output), > > b) the source property needs additional work to become usable, but it's a > more generic solution. > > So as far as I am concerned, the plan was to fix the source > property (maybe > be taking it out of RFC2518bis and to fix it in a sperate draft). > > If there were out-of-band discussions, I'd certainly like to hear > about it. > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > > Sent: Thursday, February 28, 2002 7:19 AM > > To: w3c-dist-auth@w3c.org > > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > > > > Actually, I think Lisa & I convinced Geoff (the big holdout against the > > Translate header) to give in at the last IETF meeting. Are there > > any other > > holdouts with good reason to have a problem with the translate header? > > > > --Eric > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > > > Sent: Wednesday, February 27, 2002 9:59 PM > > > To: w3c-dist-auth@w3c.org > > > Subject: A case for GETSRC (or other mechanism to that effect) > > > > > > > > > I've been reading the archives, and following the long-running and > > > sometimes contentious conversation over retrieval of source > > > documents. Maybe bringing this up will get me kicked off the list, > > > but we'll see. > > > > > > First, I appreciate what the DAV working group is trying to do by > > > allowing multiple sources for a given document, and making each > > > source a separate resource. I won't bother denying that it is useful > > > to some people and interesting in its own right. I totally see the > > > logic in it. But it is an abstraction that is useful only to a small > > > minority of users, and is very difficult to implement. If you doubt > > > that, I direct you to the total lack of implementations. But I'll > > > make a case on other grounds, as well. > > > > > > With any DAV request except GET the process is rather straightforward: > > > > > > A virtual host is selected > > > > > > Security determines what rights the user has on the URL. In > > > the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our > > > universe (WebSTAR) that means read, write, list, mkdir, etc.. > > > > > > We figure out what file the URL maps to. > > > > > > In deciding which plug-in will handle the request, a DAV > > > plug-in simply claims anything with a DAV-specific method. If it is > > > MKCOL, DELETE, etc. then the DAV plug-in claims it. > > > > > > DAV handles the request, within the limits set by the > > > security plug-in. > > > > > > All of this works great, until we get to the GET method. Plug-ins > > > have no way of knowing the difference between a normal GET that > > > should be handled normally, and a GET that is intended to retrieve > > > the source of a document and requires special permissions. In effect > > > we have TWO semantics for GET. And so we start creating fake URL > > > spaces. But we quickly run into security and configuration hassles. > > > > > > The bottom line is that there's no way to provide good DAV access > > > without some special configuration on the server. And it isn't the > > > result of some kind of design error by the implementor, but a basic > > > issue with how the protocol is designed. Unless you are only dealing > > > with static content you MUST set up a whole new URL space to do DAV > > > at all. > > > > > > In practice setting this up is such a bother that what most > > > administrators do is create a whole new virtual host with all > > > plug-ins disabled in order to get it done. Is it just me, or is it > > > entirely ridiculous that server administrators have to double the > > > number of virtual hosts they support just to give decent DAV access > > > to their users? > > > > > > And all of this is so complicated for something that *should* be > > > really simple! From most servers' point of view DAV is a way to let > > > web authors access their .php, .cgi, .ssi, .shtml, and other dynamic > > > files and edit them and save them back onto the server. All of this > > > business about an arbitrary number of sources of arbitrary types as > > > properties of a single resource don't do our users one bit of good, > > > but the implementation is quite burdensome. > > > > > > What we really need from the DAV protocol is a way to know that a > > > given request is intended to retrieve the source of a document, > > > without having to also posses knowledge about the DAV configuration, > > > or which URL spaces have been quarantined for use exclusively for > > > WebDAV, and without having to create special areas in the URL space > > > that don't actually map to anything else in the universe just so we > > > can turn off all the plug-ins for a few requests. Thus the > > > suggestion for a GETSRC property. > > > > > > I've read the arguments that ask about FINDPROP and other methods > > > that act on a resource, and having to double the number of methods to > > > support FINDPROP and FINDPROPSRC, etc.. But in most server > > > implementations when you get the properties of a .php or .ssi file > > > right now, what are you getting? In practice you're getting the > > > author and lastmod date and other information about the SOURCE, not > > > the output. I don't know of anybody who is executing a .php file and > > > then returning the properties of the output -- it (a) isn't practical > > > because of all the side-effects it would cause like CPU load and > > > errors and code running that you didn't really intend to run and (b) > > > isn't useful because nobody cares one whit about the DAV properties > > > of PHP output. > > > > > > I suggest that we just stop considering GET to be a DAV method at > > > all. GET has nothing to do with DAV any more than POST does. > > > Instead of GET, we should be using GETSRC (or whatever you want to > > > call it), always. If you want the output of a source which has been > > > run through PHP or SSI or whatever, then fire up your web browser and > > > use a GET or POST method. Otherwise, use your DAV client and GETSRC > > > (or whatever). > > > > > > When you work with the properties of a resource, you are working with > > > the properties of the resource you receive from a GETSRC command. > > > When you GETSRC, you receive the same data that you PUT. When you > > > GET or POST, you receive what the server generates from the source > > > and your input. In some cases that happens to be the same as the > > > source (static files). > > > > > > > > > If OPTIONS does not indicate that GETSRC is avialable, then a DAV > > > client may use GET instead. > > > > > > Does not preclude a document from having multiple sources at > > > different URIs, for the 5% of implementations that need such > > > functionality. > > > > > > Advantages of this approach: > > > > > > Works well with existing security modules for Apache and > > > other servers. Just add GETSRC to the list of methods a user is > > > allowed to use. > > > > > > Provides one semantic for GET (the existing semantic from > > > HTTP/1.1 spec) and only one semantic. > > > > > > Is far more likely to be implemented, and implemented WIDELY, > > > than the src property ever will be. > > > > > > > > > This is a major, major problem with the protocol. This is in not an > > > indictment of anybody's abilities. Even as a prospective implementor > > > reading the spec carefully I didn't appreciate the magnitude of the > > > problem until I set out to really implement it, and then it became > > > nearly intractable. Even the reference implementation doesn't > > > implement it. > > > > > > The DAV group can take this issue in hand and come up with a solution > > > people are willing to implement, or the ad-hoc solutions will become > > > de-facto standards. (ie: Translate). Personally, I would rather see > > > this solved by the DAV working group. > > > > > > > > > cjh > > > > > > -- > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 28 04:32:48 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15424 for ; Thu, 28 Feb 2002 04:32:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA24387; Thu, 28 Feb 2002 04:31:32 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 04:31:32 -0500 (EST) Resent-Message-Id: <200202280931.EAA24387@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 EAA24338 for ; Thu, 28 Feb 2002 04:31:01 -0500 (EST) Received: from stal-gate-out.merant.com ([62.189.101.235]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA11262 for ; Thu, 28 Feb 2002 04:31:00 -0500 Received: from stalmail.eu.merant.com (stalmail.eu.merant.com [10.130.13.220]) by stal-gate-out.merant.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id JAA20052; Thu, 28 Feb 2002 09:34:33 GMT Received: by stalmail.eu.merant.com with Internet Mail Service (5.5.2653.19) id <1LT6CWN2>; Thu, 28 Feb 2002 09:26:49 -0000 Message-ID: <20CF1CE11441D411919C0008C7C5A13B0406340A@stalmail.eu.merant.com> From: Peter Raymond To: Julian Reschke , Eric Sedlar , w3c-dist-auth@w3c.org Date: Thu, 28 Feb 2002 09:26:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C03A.07978050" Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5961 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_01C1C03A.07978050 Content-Type: text/plain; charset="iso-8859-1" Hi, This also surprises me...(see this section from the Salt Lake City IETF meeting minutes.... Getting source code... DAV:source too complex? Take out of 2518, put in it's own spec if people need it. Translate only does 1:1 We took a vote and 4 people were in favour of removing DAV:source, #nobody opposed this. Translate header works well because it's Microsoft and because most servers have one-2-one mapping...eg they edit JSP but not CGI (eg C code) Larry - Why not use a proxy that translates the Translate header into a DAV:source request?? Geoffs objection to translate is that it needs defining for all methods not just a few as it is today. Clients put the translate header on every request if it is working on the source (eg in authoring mode). I seem to remember (and the above enforces this memory) that we took a vote to remove DAV:source from RFC2518 and we agreed. If we fix DAV:source or if we use the Translate header I still think it needs to go into a separate specification for several reasons: - For RFC2518 to move through the standards track we need to show interoperability of this feature and we cannot do that today, we cannot even agree on the best solution - As far as I know we have not seen any clients/servers use the DAV:source property (eg it is not implemented). - I am also interested in managing more than just websites and may need a more advanced way of navigating relationships (perhaps between design documents and the code that implements them or between firmware and circuit board designs etc). This can best be addressed in another specification. Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: 28 February 2002 09:06 To: Eric Sedlar; w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) Eric, that comes as a suprise. As far as I remember the discussion we concluced that: a) the Translate header (or GETSRC) solves only a very specific part of the problem (when there's a one-to-one mapping between source and output), b) the source property needs additional work to become usable, but it's a more generic solution. So as far as I am concerned, the plan was to fix the source property (maybe be taking it out of RFC2518bis and to fix it in a sperate draft). If there were out-of-band discussions, I'd certainly like to hear about it. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Thursday, February 28, 2002 7:19 AM > To: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > Actually, I think Lisa & I convinced Geoff (the big holdout against the > Translate header) to give in at the last IETF meeting. Are there > any other > holdouts with good reason to have a problem with the translate header? > > --Eric > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > > Sent: Wednesday, February 27, 2002 9:59 PM > > To: w3c-dist-auth@w3c.org > > Subject: A case for GETSRC (or other mechanism to that effect) > > > > > > I've been reading the archives, and following the long-running and > > sometimes contentious conversation over retrieval of source > > documents. Maybe bringing this up will get me kicked off the list, > > but we'll see. > > > > First, I appreciate what the DAV working group is trying to do by > > allowing multiple sources for a given document, and making each > > source a separate resource. I won't bother denying that it is useful > > to some people and interesting in its own right. I totally see the > > logic in it. But it is an abstraction that is useful only to a small > > minority of users, and is very difficult to implement. If you doubt > > that, I direct you to the total lack of implementations. But I'll > > make a case on other grounds, as well. > > > > With any DAV request except GET the process is rather straightforward: > > > > A virtual host is selected > > > > Security determines what rights the user has on the URL. In > > the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our > > universe (WebSTAR) that means read, write, list, mkdir, etc.. > > > > We figure out what file the URL maps to. > > > > In deciding which plug-in will handle the request, a DAV > > plug-in simply claims anything with a DAV-specific method. If it is > > MKCOL, DELETE, etc. then the DAV plug-in claims it. > > > > DAV handles the request, within the limits set by the > > security plug-in. > > > > All of this works great, until we get to the GET method. Plug-ins > > have no way of knowing the difference between a normal GET that > > should be handled normally, and a GET that is intended to retrieve > > the source of a document and requires special permissions. In effect > > we have TWO semantics for GET. And so we start creating fake URL > > spaces. But we quickly run into security and configuration hassles. > > > > The bottom line is that there's no way to provide good DAV access > > without some special configuration on the server. And it isn't the > > result of some kind of design error by the implementor, but a basic > > issue with how the protocol is designed. Unless you are only dealing > > with static content you MUST set up a whole new URL space to do DAV > > at all. > > > > In practice setting this up is such a bother that what most > > administrators do is create a whole new virtual host with all > > plug-ins disabled in order to get it done. Is it just me, or is it > > entirely ridiculous that server administrators have to double the > > number of virtual hosts they support just to give decent DAV access > > to their users? > > > > And all of this is so complicated for something that *should* be > > really simple! From most servers' point of view DAV is a way to let > > web authors access their .php, .cgi, .ssi, .shtml, and other dynamic > > files and edit them and save them back onto the server. All of this > > business about an arbitrary number of sources of arbitrary types as > > properties of a single resource don't do our users one bit of good, > > but the implementation is quite burdensome. > > > > What we really need from the DAV protocol is a way to know that a > > given request is intended to retrieve the source of a document, > > without having to also posses knowledge about the DAV configuration, > > or which URL spaces have been quarantined for use exclusively for > > WebDAV, and without having to create special areas in the URL space > > that don't actually map to anything else in the universe just so we > > can turn off all the plug-ins for a few requests. Thus the > > suggestion for a GETSRC property. > > > > I've read the arguments that ask about FINDPROP and other methods > > that act on a resource, and having to double the number of methods to > > support FINDPROP and FINDPROPSRC, etc.. But in most server > > implementations when you get the properties of a .php or .ssi file > > right now, what are you getting? In practice you're getting the > > author and lastmod date and other information about the SOURCE, not > > the output. I don't know of anybody who is executing a .php file and > > then returning the properties of the output -- it (a) isn't practical > > because of all the side-effects it would cause like CPU load and > > errors and code running that you didn't really intend to run and (b) > > isn't useful because nobody cares one whit about the DAV properties > > of PHP output. > > > > I suggest that we just stop considering GET to be a DAV method at > > all. GET has nothing to do with DAV any more than POST does. > > Instead of GET, we should be using GETSRC (or whatever you want to > > call it), always. If you want the output of a source which has been > > run through PHP or SSI or whatever, then fire up your web browser and > > use a GET or POST method. Otherwise, use your DAV client and GETSRC > > (or whatever). > > > > When you work with the properties of a resource, you are working with > > the properties of the resource you receive from a GETSRC command. > > When you GETSRC, you receive the same data that you PUT. When you > > GET or POST, you receive what the server generates from the source > > and your input. In some cases that happens to be the same as the > > source (static files). > > > > > > If OPTIONS does not indicate that GETSRC is avialable, then a DAV > > client may use GET instead. > > > > Does not preclude a document from having multiple sources at > > different URIs, for the 5% of implementations that need such > > functionality. > > > > Advantages of this approach: > > > > Works well with existing security modules for Apache and > > other servers. Just add GETSRC to the list of methods a user is > > allowed to use. > > > > Provides one semantic for GET (the existing semantic from > > HTTP/1.1 spec) and only one semantic. > > > > Is far more likely to be implemented, and implemented WIDELY, > > than the src property ever will be. > > > > > > This is a major, major problem with the protocol. This is in not an > > indictment of anybody's abilities. Even as a prospective implementor > > reading the spec carefully I didn't appreciate the magnitude of the > > problem until I set out to really implement it, and then it became > > nearly intractable. Even the reference implementation doesn't > > implement it. > > > > The DAV group can take this issue in hand and come up with a solution > > people are willing to implement, or the ad-hoc solutions will become > > de-facto standards. (ie: Translate). Personally, I would rather see > > this solved by the DAV working group. > > > > > > cjh > > > > -- > > > > > ------_=_NextPart_001_01C1C03A.07978050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A case for GETSRC (or other mechanism to that = effect)

Hi,

This also surprises me...(see this section from the = Salt Lake City IETF meeting
minutes....


        Getting = source code...

        DAV:source = too complex?
        Take out = of 2518, put in it's own spec if people need it.
        Translate = only does 1:1
        We took a = vote and 4 people were in favour of removing DAV:source,
        #nobody = opposed this.
        Translate = header works well because it's Microsoft and because most servers have = one-2-one mapping...eg they    edit JSP but not CGI (eg C = code)

        Larry - = Why not use a proxy that translates the Translate header into a = DAV:source request??
        Geoffs = objection to translate is that it needs defining for all methods not = just a few as it is today.
        Clients = put the translate header on every request if it is working on the = source (eg in authoring mode).

I seem to remember (and the above enforces this = memory) that we took a vote to remove DAV:source
from RFC2518 and we agreed.  If we fix = DAV:source or if we use the Translate header I still think
it needs to go into a separate specification for = several reasons:

- For RFC2518 to move through the standards track we = need to show interoperability of this feature
  and we cannot do that today, we cannot even = agree on the best solution

- As far as I know we have not seen any = clients/servers use the DAV:source property (eg it is not
  implemented).

- I am also interested in managing more than just = websites and may need a more advanced way of
  navigating relationships (perhaps between = design documents and the code that implements them or
  between firmware and circuit board designs = etc).  This can best be addressed in another specification.

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



-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: 28 February 2002 09:06
To: Eric Sedlar; w3c-dist-auth@w3c.org
Subject: RE: A case for GETSRC (or other mechanism = to that effect)


Eric,

that comes as a suprise.

As far as I remember the discussion we concluced = that:

a) the Translate header (or GETSRC) solves only a = very specific part of the
problem (when there's a one-to-one mapping between = source and output),

b) the source property needs additional work to = become usable, but it's a
more generic solution.

So as far as I am concerned, the plan was to fix the = source property (maybe
be taking it out of RFC2518bis and to fix it in a = sperate draft).

If there were out-of-band discussions, I'd certainly = like to hear about it.

Julian

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-reques= t@w3.org]On Behalf Of Eric Sedlar
> Sent: Thursday, February 28, 2002 7:19 = AM
> To: w3c-dist-auth@w3c.org
> Subject: RE: A case for GETSRC (or other = mechanism to that effect)
>
>
> Actually, I think Lisa & I convinced Geoff = (the big holdout against the
> Translate header) to give in at the last IETF = meeting.  Are there
> any other
> holdouts with good reason to have a problem = with the translate header?
>
> --Eric
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-reques= t@w3.org]On Behalf Of CJ Holmes
> > Sent: Wednesday, February 27, 2002 9:59 = PM
> > To: w3c-dist-auth@w3c.org
> > Subject: A case for GETSRC (or other = mechanism to that effect)
> >
> >
> > I've been reading the archives, and = following the long-running and
> > sometimes contentious conversation over = retrieval of source
> > documents.  Maybe bringing this up = will get me kicked off the list,
> > but we'll see.
> >
> > First, I appreciate what the DAV working = group is trying to do by
> > allowing multiple sources for a given = document, and making each
> > source a separate resource.  I won't = bother denying that it is useful
> > to some people and interesting in its own = right.  I totally see the
> > logic in it.  But it is an = abstraction that is useful only to a small
> > minority of users, and is very difficult = to implement.  If you doubt
> > that, I direct you to the total lack of = implementations.  But I'll
> > make a case on other grounds, as = well.
> >
> > With any DAV request except GET the = process is rather straightforward:
> >
> >     A virtual host is = selected
> >
> >     Security determines = what rights the user has on the URL.  In
> > the Apache universe that means PUT, POST, = MKCOL, GET, etc..  In our
> > universe (WebSTAR) that means read, write, = list, mkdir, etc..
> >
> >     We figure out what file = the URL maps to.
> >
> >     In deciding which = plug-in will handle the request, a DAV
> > plug-in simply claims anything with a = DAV-specific method.  If it is
> > MKCOL, DELETE, etc. then the DAV plug-in = claims it.
> >
> >     DAV handles the = request, within the limits set by the
> > security plug-in.
> >
> > All of this works great, until we get to = the GET method.  Plug-ins
> > have no way of knowing the difference = between a normal GET that
> > should be handled normally, and a GET that = is intended to retrieve
> > the source of a document and requires = special permissions.  In effect
> > we have TWO semantics for GET.  And = so we start creating fake URL
> > spaces.  But we quickly run into = security and configuration hassles.
> >
> > The bottom line is that there's no way to = provide good DAV access
> > without some special configuration on the = server.  And it isn't the
> > result of some kind of design error by the = implementor, but a basic
> > issue with how the protocol is = designed.  Unless you are only dealing
> > with static content you MUST set up a = whole new URL space to do DAV
> > at all.
> >
> > In practice setting this up is such a = bother that what most
> > administrators do is create a whole new = virtual host with all
> > plug-ins disabled in order to get it = done.  Is it just me, or is it
> > entirely ridiculous that server = administrators have to double the
> > number of virtual hosts they support just = to give decent DAV access
> > to their users?
> >
> > And all of this is so complicated for = something that *should* be
> > really simple!  From most servers' = point of view DAV is a way to let
> > web authors access their .php, .cgi, .ssi, = .shtml, and other dynamic
> > files and edit them and save them back = onto the server.  All of this
> > business about an arbitrary number of = sources of arbitrary types as
> > properties of a single resource don't do = our users one bit of good,
> > but the implementation is quite = burdensome.
> >
> > What we really need from the DAV protocol = is a way to know that a
> > given request is intended to retrieve the = source of a document,
> > without having to also posses knowledge = about the DAV configuration,
> > or which URL spaces have been quarantined = for use exclusively for
> > WebDAV, and without having to create = special areas in the URL space
> > that don't actually map to anything else = in the universe just so we
> > can turn off all the plug-ins for a few = requests.  Thus the
> > suggestion for a GETSRC property.
> >
> > I've read the arguments that ask about = FINDPROP and other methods
> > that act on a resource, and having to = double the number of methods to
> > support FINDPROP and FINDPROPSRC, = etc..  But in most server
> > implementations when you get the = properties of a .php or .ssi file
> > right now, what are you getting?  In = practice you're getting the
> > author and lastmod date and other = information about the SOURCE, not
> > the output.  I don't know of anybody = who is executing a .php file and
> > then returning the properties of the = output -- it (a) isn't practical
> > because of all the side-effects it would = cause like CPU load and
> > errors and code running that you didn't = really intend to run and (b)
> > isn't useful because nobody cares one whit = about the DAV properties
> > of PHP output.
> >
> > I suggest that we just stop considering = GET to be a DAV method at
> > all.  GET has nothing to do with DAV = any more than POST does.
> > Instead of GET, we should be using GETSRC = (or whatever you want to
> > call it), always.  If you want the = output of a source which has been
> > run through PHP or SSI or whatever, then = fire up your web browser and
> > use a GET or POST method.  Otherwise, = use your DAV client and GETSRC
> > (or whatever).
> >
> > When you work with the properties of a = resource, you are working with
> > the properties of the resource you receive = from a GETSRC command.
> > When you GETSRC, you receive the same data = that you PUT.  When you
> > GET or POST, you receive what the server = generates from the source
> > and your input.  In some cases that = happens to be the same as the
> > source (static files).
> >
> >
> > If OPTIONS does not indicate that GETSRC = is avialable, then a DAV
> > client may use GET instead.
> >
> > Does not preclude a document from having = multiple sources at
> > different URIs, for the 5% of = implementations that need such
> > functionality.
> >
> > Advantages of this approach:
> >
> >     Works well with = existing security modules for Apache and
> > other servers.  Just add GETSRC to = the list of methods a user is
> > allowed to use.
> >
> >     Provides one semantic = for GET (the existing semantic from
> > HTTP/1.1 spec) and only one = semantic.
> >
> >     Is far more likely to = be implemented, and implemented WIDELY,
> > than the src property ever will be.
> >
> >
> > This is a major, major problem with the = protocol.  This is in not an
> > indictment of anybody's abilities.  = Even as a prospective implementor
> > reading the spec carefully I didn't = appreciate the magnitude of the
> > problem until I set out to really = implement it, and then it became
> > nearly intractable.  Even the = reference implementation doesn't
> > implement it.
> >
> > The DAV group can take this issue in hand = and come up with a solution
> > people are willing to implement, or the = ad-hoc solutions will become
> > de-facto standards.  (ie: = Translate).  Personally, I would rather see
> > this solved by the DAV working = group.
> >
> >
> > cjh
> >
> > --
> >
> >
>

------_=_NextPart_001_01C1C03A.07978050-- From w3c-dist-auth-request@w3.org Thu Feb 28 04:44:30 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15550 for ; Thu, 28 Feb 2002 04:44:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA25083; Thu, 28 Feb 2002 04:43:12 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 04:43:12 -0500 (EST) Resent-Message-Id: <200202280943.EAA25083@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 EAA25019 for ; Thu, 28 Feb 2002 04:42:46 -0500 (EST) 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 EAA12679 for ; Thu, 28 Feb 2002 04:42:45 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1S9giG21954; Thu, 28 Feb 2002 01:42:44 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g1S9ggI16178; Thu, 28 Feb 2002 02:42:42 -0700 (MST) From: "Eric Sedlar" To: "Peter Raymond" , "Julian Reschke" , Date: Thu, 28 Feb 2002 01:42:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01C1BFF9.333CA960" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20CF1CE11441D411919C0008C7C5A13B0406340A@stalmail.eu.merant.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5962 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_009F_01C1BFF9.333CA960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: A case for GETSRC (or other mechanism to that effect)Comments inlined... -----Original Message----- From: Peter Raymond [mailto:Peter.Raymond@merant.com] Sent: Thursday, February 28, 2002 1:27 AM To: Julian Reschke; Eric Sedlar; w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) Hi, This also surprises me...(see this section from the Salt Lake City IETF meeting minutes.... Getting source code... DAV:source too complex? Take out of 2518, put in it's own spec if people need it. Translate only does 1:1 We took a vote and 4 people were in favour of removing DAV:source, #nobody opposed this. Translate header works well because it's Microsoft and because most servers have one-2-one mapping...eg they edit JSP but not CGI (eg C code) Larry - Why not use a proxy that translates the Translate header into a DAV:source request?? Geoffs objection to translate is that it needs defining for all methods not just a few as it is today. Clients put the translate header on every request if it is working on the source (eg in authoring mode). The proposal would be that Translate: F would only have an effect on the GET method, and could be either ignored or forbidden on other methods ( one of the nits that Geoff picked at at the dinner where we won him over)... I seem to remember (and the above enforces this memory) that we took a vote to remove DAV:source from RFC2518 and we agreed. If we fix DAV:source or if we use the Translate header I still think it needs to go into a separate specification for several reasons: - For RFC2518 to move through the standards track we need to show interoperability of this feature and we cannot do that today, we cannot even agree on the best solution There is certainly interoperability for Translate: F, so I don't see why that needs to go into a separate spec. - As far as I know we have not seen any clients/servers use the DAV:source property (eg it is not implemented). Agreed. dav:source is basically useless with today's servers - I am also interested in managing more than just websites and may need a more advanced way of navigating relationships (perhaps between design documents and the code that implements them or between firmware and circuit board designs etc). This can best be addressed in another specification. The issue of how the executable is generated is a separate question from getting at the executable content itself (see my reply to Julian's email). Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: 28 February 2002 09:06 To: Eric Sedlar; w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) Eric, that comes as a suprise. As far as I remember the discussion we concluced that: a) the Translate header (or GETSRC) solves only a very specific part of the problem (when there's a one-to-one mapping between source and output), b) the source property needs additional work to become usable, but it's a more generic solution. So as far as I am concerned, the plan was to fix the source property (maybe be taking it out of RFC2518bis and to fix it in a sperate draft). If there were out-of-band discussions, I'd certainly like to hear about it. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Thursday, February 28, 2002 7:19 AM > To: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > Actually, I think Lisa & I convinced Geoff (the big holdout against the > Translate header) to give in at the last IETF meeting. Are there > any other > holdouts with good reason to have a problem with the translate header? > > --Eric > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > > Sent: Wednesday, February 27, 2002 9:59 PM > > To: w3c-dist-auth@w3c.org > > Subject: A case for GETSRC (or other mechanism to that effect) > > > > > > I've been reading the archives, and following the long-running and > > sometimes contentious conversation over retrieval of source > > documents. Maybe bringing this up will get me kicked off the list, > > but we'll see. > > > > First, I appreciate what the DAV working group is trying to do by > > allowing multiple sources for a given document, and making each > > source a separate resource. I won't bother denying that it is useful > > to some people and interesting in its own right. I totally see the > > logic in it. But it is an abstraction that is useful only to a small > > minority of users, and is very difficult to implement. If you doubt > > that, I direct you to the total lack of implementations. But I'll > > make a case on other grounds, as well. > > > > With any DAV request except GET the process is rather straightforward: > > > > A virtual host is selected > > > > Security determines what rights the user has on the URL. In > > the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our > > universe (WebSTAR) that means read, write, list, mkdir, etc.. > > > > We figure out what file the URL maps to. > > > > In deciding which plug-in will handle the request, a DAV > > plug-in simply claims anything with a DAV-specific method. If it is > > MKCOL, DELETE, etc. then the DAV plug-in claims it. > > > > DAV handles the request, within the limits set by the > > security plug-in. > > > > All of this works great, until we get to the GET method. Plug-ins > > have no way of knowing the difference between a normal GET that > > should be handled normally, and a GET that is intended to retrieve > > the source of a document and requires special permissions. In effect > > we have TWO semantics for GET. And so we start creating fake URL > > spaces. But we quickly run into security and configuration hassles. > > > > The bottom line is that there's no way to provide good DAV access > > without some special configuration on the server. And it isn't the > > result of some kind of design error by the implementor, but a basic > > issue with how the protocol is designed. Unless you are only dealing > > with static content you MUST set up a whole new URL space to do DAV > > at all. > > > > In practice setting this up is such a bother that what most > > administrators do is create a whole new virtual host with all > > plug-ins disabled in order to get it done. Is it just me, or is it > > entirely ridiculous that server administrators have to double the > > number of virtual hosts they support just to give decent DAV access > > to their users? > > > > And all of this is so complicated for something that *should* be > > really simple! From most servers' point of view DAV is a way to let > > web authors access their .php, .cgi, .ssi, .shtml, and other dynamic > > files and edit them and save them back onto the server. All of this > > business about an arbitrary number of sources of arbitrary types as > > properties of a single resource don't do our users one bit of good, > > but the implementation is quite burdensome. > > > > What we really need from the DAV protocol is a way to know that a > > given request is intended to retrieve the source of a document, > > without having to also posses knowledge about the DAV configuration, > > or which URL spaces have been quarantined for use exclusively for > > WebDAV, and without having to create special areas in the URL space > > that don't actually map to anything else in the universe just so we > > can turn off all the plug-ins for a few requests. Thus the > > suggestion for a GETSRC property. > > > > I've read the arguments that ask about FINDPROP and other methods > > that act on a resource, and having to double the number of methods to > > support FINDPROP and FINDPROPSRC, etc.. But in most server > > implementations when you get the properties of a .php or .ssi file > > right now, what are you getting? In practice you're getting the > > author and lastmod date and other information about the SOURCE, not > > the output. I don't know of anybody who is executing a .php file and > > then returning the properties of the output -- it (a) isn't practical > > because of all the side-effects it would cause like CPU load and > > errors and code running that you didn't really intend to run and (b) > > isn't useful because nobody cares one whit about the DAV properties > > of PHP output. > > > > I suggest that we just stop considering GET to be a DAV method at > > all. GET has nothing to do with DAV any more than POST does. > > Instead of GET, we should be using GETSRC (or whatever you want to > > call it), always. If you want the output of a source which has been > > run through PHP or SSI or whatever, then fire up your web browser and > > use a GET or POST method. Otherwise, use your DAV client and GETSRC > > (or whatever). > > > > When you work with the properties of a resource, you are working with > > the properties of the resource you receive from a GETSRC command. > > When you GETSRC, you receive the same data that you PUT. When you > > GET or POST, you receive what the server generates from the source > > and your input. In some cases that happens to be the same as the > > source (static files). > > > > > > If OPTIONS does not indicate that GETSRC is avialable, then a DAV > > client may use GET instead. > > > > Does not preclude a document from having multiple sources at > > different URIs, for the 5% of implementations that need such > > functionality. > > > > Advantages of this approach: > > > > Works well with existing security modules for Apache and > > other servers. Just add GETSRC to the list of methods a user is > > allowed to use. > > > > Provides one semantic for GET (the existing semantic from > > HTTP/1.1 spec) and only one semantic. > > > > Is far more likely to be implemented, and implemented WIDELY, > > than the src property ever will be. > > > > > > This is a major, major problem with the protocol. This is in not an > > indictment of anybody's abilities. Even as a prospective implementor > > reading the spec carefully I didn't appreciate the magnitude of the > > problem until I set out to really implement it, and then it became > > nearly intractable. Even the reference implementation doesn't > > implement it. > > > > The DAV group can take this issue in hand and come up with a solution > > people are willing to implement, or the ad-hoc solutions will become > > de-facto standards. (ie: Translate). Personally, I would rather see > > this solved by the DAV working group. > > > > > > cjh > > > > -- > > > > > ------=_NextPart_000_009F_01C1BFF9.333CA960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A case for GETSRC (or other mechanism to that = effect)
Comments inlined...
-----Original Message-----
From: Peter Raymond=20 [mailto:Peter.Raymond@merant.com]
Sent: Thursday, February = 28, 2002=20 1:27 AM
To: Julian Reschke; Eric Sedlar;=20 w3c-dist-auth@w3c.org
Subject: RE: A case for GETSRC (or = other=20 mechanism to that effect)

Hi,

This also surprises me...(see this section from the = Salt Lake=20 City IETF meeting
minutes.... =


        Getting = source=20 code...

        DAV:source too=20 complex?
        Take out of 2518, put in it's own spec if people need it.=20
        Translate=20 only does 1:1
        = We took a vote and 4 people were in favour of removing = DAV:source,=20
        #nobody=20 opposed this.
        = Translate header works well because it's Microsoft and = because most=20 servers have one-2-one mapping...eg they    edit JSP but not = CGI (eg=20 C code)

        Larry - = Why not use=20 a proxy that translates the Translate header into a DAV:source = request??=20
        Geoffs=20 objection to translate is that it needs defining for all methods not = just a=20 few as it is today. =
       =20 Clients put the translate header on every request if it = is=20 working on the source (eg in authoring mode).  

The proposal would be that Translate: F = would only=20 have an effect on the GET method, and could be either ignored or=20 forbidden on other methods ( one of the nits that Geoff picked = at at the=20 dinner where we won him over)...

I seem to remember (and the above enforces this = memory) that=20 we took a vote to remove DAV:source
from = RFC2518 and=20 we agreed.  If we fix DAV:source or if we use the Translate = header I=20 still think
it needs to go into a separate=20 specification for several reasons:

- For RFC2518 to move through the standards track we = need to=20 show interoperability of this feature
  = and we=20 cannot do that today, we cannot even agree on the best=20 solution  

There=20 is certainly interoperability for Translate: F, so I don't see why = that needs=20 to go into a separate spec.

- As far as I know we have not seen any = clients/servers use=20 the DAV:source property (eg it is not
  = implemented).  

Agreed.  dav:source is = basically useless=20 with today's servers 

- I am also interested in managing more than just = websites and=20 may need a more advanced way of
  = navigating=20 relationships (perhaps between design documents and the code that = implements=20 them or
  between firmware and circuit = board=20 designs etc).  This can best be addressed in another=20 specification.  

The=20 issue of how the executable is generated is a separate question=20 from getting at the executable content itself (see my reply=20 to Julian's email). 

Regards,
-- =
Peter Raymond - MERANT
Principal = Architect=20 (PVCS)
Tel: +44 (0)1727 813362 =
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com<= /A>=20
WWW: http://www.merant.com



-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20
Sent: 28 February 2002 09:06
To: Eric=20 Sedlar; w3c-dist-auth@w3c.org
Subject: RE: A = case for=20 GETSRC (or other mechanism to that effect)


Eric,

that comes as a suprise.

As far as I remember the discussion we concluced = that:=20

a) the Translate header (or GETSRC) solves only a = very=20 specific part of the
problem (when there's a = one-to-one mapping between source and output),

b) the source property needs additional work to = become usable,=20 but it's a
more generic solution. =

So as far as I am concerned, the plan was to fix the = source=20 property (maybe
be taking it out of = RFC2518bis and to=20 fix it in a sperate draft).

If there were out-of-band discussions, I'd certainly = like to=20 hear about it.

Julian

> -----Original Message-----
>=20 From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request= @w3.org]On=20 Behalf Of Eric Sedlar
> Sent: Thursday, = February=20 28, 2002 7:19 AM
> To: = w3c-dist-auth@w3c.org=20
> Subject: RE: A case for GETSRC (or other = mechanism to=20 that effect)
>
>=20
> Actually, I think Lisa & I convinced Geoff = (the big=20 holdout against the
> Translate header) = to give in=20 at the last IETF meeting.  Are there
> any=20 other
> holdouts with good reason to have = a problem=20 with the translate header?
> =
> --Eric
>
>=20 > -----Original Message-----
> > = From:=20 w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request= @w3.org]On=20 Behalf Of CJ Holmes
> > Sent: = Wednesday,=20 February 27, 2002 9:59 PM
> > To:=20 w3c-dist-auth@w3c.org
> > Subject: A = case for=20 GETSRC (or other mechanism to that effect)
>=20 >
> >
> > I've=20 been reading the archives, and following the long-running and =
> > sometimes contentious conversation over retrieval = of=20 source
> > documents.  Maybe = bringing this=20 up will get me kicked off the list,
> = > but=20 we'll see.
> >
> >=20 First, I appreciate what the DAV working group is trying to do = by=20
> > allowing multiple sources for a given = document, and=20 making each
> > source a separate=20 resource.  I won't bother denying that it is useful =
> > to some people and interesting in its own = right.  I=20 totally see the
> > logic in it.  = But it is=20 an abstraction that is useful only to a small
>=20 > minority of users, and is very difficult to implement.  If = you=20 doubt
> > that, I direct you to the = total lack=20 of implementations.  But I'll
> > = make a=20 case on other grounds, as well.
> = >=20
> > With any DAV request except GET the = process is=20 rather straightforward:
> > =
> >     A virtual host is = selected=20
> >
> >=20     Security determines what rights the user has on the = URL.  In
> > the Apache universe = that means=20 PUT, POST, MKCOL, GET, etc..  In our
> >=20 universe (WebSTAR) that means read, write, list, mkdir, etc.. =
> >
> > =     We=20 figure out what file the URL maps to.
> = >=20
> >     In deciding which = plug-in will=20 handle the request, a DAV
> > plug-in = simply=20 claims anything with a DAV-specific method.  If it is =
> > MKCOL, DELETE, etc. then the DAV plug-in claims = it.=20
> >
> >=20     DAV handles the request, within the limits set by=20 the
> > security plug-in. =
> >
> > All of this = works great,=20 until we get to the GET method.  Plug-ins
>=20 > have no way of knowing the difference between a normal GET = that=20
> > should be handled normally, and a GET = that is=20 intended to retrieve
> > the source of = a=20 document and requires special permissions.  In effect =
> > we have TWO semantics for GET.  And so we = start creating=20 fake URL
> > spaces.  But we = quickly run=20 into security and configuration hassles.
>=20 >
> > The bottom line is that = there's no way=20 to provide good DAV access
> > without = some=20 special configuration on the server.  And it isn't the =
> > result of some kind of design error by the = implementor, but a=20 basic
> > issue with how the protocol = is=20 designed.  Unless you are only dealing
> >=20 with static content you MUST set up a whole new URL space to do = DAV=20
> > at all.
> = >=20
> > In practice setting this up is such a = bother that=20 what most
> > administrators do is = create a=20 whole new virtual host with all
> > = plug-ins=20 disabled in order to get it done.  Is it just me, or is it =
> > entirely ridiculous that server = administrators have=20 to double the
> > number of virtual = hosts they=20 support just to give decent DAV access
> = > to=20 their users?
> >
>=20 > And all of this is so complicated for something that *should* = be=20
> > really simple!  From most servers' = point of=20 view DAV is a way to let
> > web = authors access=20 their .php, .cgi, .ssi, .shtml, and other dynamic
>=20 > files and edit them and save them back onto the server.  All = of=20 this
> > business about an arbitrary = number of=20 sources of arbitrary types as
> > = properties of=20 a single resource don't do our users one bit of good,
> > but the implementation is quite burdensome. =
> >
> > What we really = need from=20 the DAV protocol is a way to know that a
> >=20 given request is intended to retrieve the source of a document, =
> > without having to also posses knowledge = about the=20 DAV configuration,
> > or which URL = spaces have=20 been quarantined for use exclusively for
> >=20 WebDAV, and without having to create special areas in the URL = space=20
> > that don't actually map to anything else = in the=20 universe just so we
> > can turn off = all the=20 plug-ins for a few requests.  Thus the
> >=20 suggestion for a GETSRC property.
> = >=20
> > I've read the arguments that ask about = FINDPROP and=20 other methods
> > that act on a = resource, and=20 having to double the number of methods to
> >=20 support FINDPROP and FINDPROPSRC, etc..  But in most = server=20
> > implementations when you get the = properties of a=20 .php or .ssi file
> > right now, what = are you=20 getting?  In practice you're getting the
>=20 > author and lastmod date and other information about the SOURCE,=20 not
> > the output.  I don't know = of=20 anybody who is executing a .php file and
> >=20 then returning the properties of the output -- it (a) isn't = practical=20
> > because of all the side-effects it would = cause like=20 CPU load and
> > errors and code = running that=20 you didn't really intend to run and (b)
> = >=20 isn't useful because nobody cares one whit about the DAV = properties=20
> > of PHP output.
>=20 >
> > I suggest that we just stop = considering=20 GET to be a DAV method at
> > = all.  GET has=20 nothing to do with DAV any more than POST does.
>=20 > Instead of GET, we should be using GETSRC (or whatever you want = to=20
> > call it), always.  If you want the = output of a=20 source which has been
> > run through = PHP or SSI=20 or whatever, then fire up your web browser and
>=20 > use a GET or POST method.  Otherwise, use your DAV client = and=20 GETSRC
> > (or whatever). =
> >
> > When you work = with the=20 properties of a resource, you are working with
>=20 > the properties of the resource you receive from a GETSRC = command.=20
> > When you GETSRC, you receive the same = data that you=20 PUT.  When you
> > GET or POST, = you receive=20 what the server generates from the source
> >=20 and your input.  In some cases that happens to be the same as = the=20
> > source (static files).
>=20 >
> >
> > If=20 OPTIONS does not indicate that GETSRC is avialable, then a DAV=20
> > client may use GET instead. =
> >
> > Does not = preclude a=20 document from having multiple sources at
> >=20 different URIs, for the 5% of implementations that need such =
> > functionality.
> = >=20
> > Advantages of this approach: =
> >
> > =     Works=20 well with existing security modules for Apache and
> > other servers.  Just add GETSRC to the list of = methods a=20 user is
> > allowed to use. =
> >
> > =     Provides=20 one semantic for GET (the existing semantic from
>=20 > HTTP/1.1 spec) and only one semantic.
>=20 >
> >     Is far = more likely=20 to be implemented, and implemented WIDELY,
> >=20 than the src property ever will be.
> = >=20
> >
> > This = is a major,=20 major problem with the protocol.  This is in not an =
> > indictment of anybody's abilities.  Even as a=20 prospective implementor
> > reading = the spec=20 carefully I didn't appreciate the magnitude of the
> > problem until I set out to really implement it, and = then it=20 became
> > nearly intractable.  = Even the=20 reference implementation doesn't
> > = implement=20 it.
> >
> = > The=20 DAV group can take this issue in hand and come up with a = solution=20
> > people are willing to implement, or the = ad-hoc=20 solutions will become
> > de-facto=20 standards.  (ie: Translate).  Personally, I would rather = see=20
> > this solved by the DAV working = group.=20
> >
> = >
> > cjh
> > =
> > --
> > =
> >
>=20

------=_NextPart_000_009F_01C1BFF9.333CA960-- From w3c-dist-auth-request@w3.org Thu Feb 28 06:01:47 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16731 for ; Thu, 28 Feb 2002 06:01:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA00626; Thu, 28 Feb 2002 06:00:32 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 06:00:32 -0500 (EST) Resent-Message-Id: <200202281100.GAA00626@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 GAA00554 for ; Thu, 28 Feb 2002 06:00:00 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA22989 for ; Thu, 28 Feb 2002 05:59:59 -0500 Received: (qmail 24485 invoked by uid 0); 28 Feb 2002 10:59:28 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 28 Feb 2002 10:59:28 -0000 From: "Julian Reschke" To: Date: Thu, 28 Feb 2002 11:59:28 +0100 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.2600.0000 In-reply-to: Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5963 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 Eric Sedlar > Sent: Thursday, February 28, 2002 10:25 AM > To: Julian Reschke; w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > I think the point is that for every method other than GET, the method > operates on a particular source object, not a set of them. dav:source is > actually trying to track one level beyond that. Translate: F, or > GETSRC, is > just trying to get back the same contents that were PUT to that location. Actually, with dav:source and multiple URIs PUTting to the non-source result would result in an error (or at least wouldn't have any effect at all). > The only time Translate/GETSRC is relevant is for executables (cgi's, > servlets, etc.) at a particular URL which generate some dynamic content. I don't agree. DAV:source may be relevant for "compiled" resources as well. For instance, static HTML might be generated by a one-time compilation process, but you don't want anybody to *modify* the HTML. Rather, people would need to be pointed to the modifiable source (for instance, XML and XSLT input files). > So, there are really three different sets of content we are looking at: > > 1) the generated output returned by GET > > 2) the executable that generates the content for GET, and which is the > object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK, > MOVE, COPY, > ...) I don't think I agree. PROPFIND etc. should access the same resource as GET (if they are applied to the same URI). > 3) the multiple source files that were used to generate the executable > > > The GET method returns resource #1, dav:source (if it were actually > implemented by anyone) would list #3. Translate: F, or GETSRC, returns > resource #2, which is the one logically consistent with the other WebDAV > methods. Yes, but dav:source can do this for you as well. Why have two different models if one is enough? > Actually figuring out #3 is something the equivalent of makefile > dependency > tracking, and is not generally available even in a development > environment, > which is something that WebDAV is certainly not. That would only be a problem if WebDAV required that the list of sources is exhaustive. It doesn't. It's just a hint to a client where to look for files that actually *affect* the resource when edited. > Real-world experience has shown that: > > * nobody actually tracks multiple source files for an executable > * people sometimes want to actually get the executable contents > > Nobody has actually come up with a real-world use-case for dav:source, but > whether or not dav:source is deprecated or not, it's actually > identifying a > different set of content than Translate: F / GETSRC. I disagree. Could you please explain why the model used in DAV:source can't be applied to this use case? > And, once you realize that you need Translate: F or GETSRC, you might as > well use Translate: F, as you will have no problem getting interoperable > implementations, and it is functionally equivalent to GETSRC. Using the same URI for "the" source (assuming there is only one) and the output means that you can't point people explicitly to one of them. As user agents generally aren't aware of the Translate header (or GETSRC), they would fetch the output resource, so basically you have a source resource which you can't refer to. Actually, having a one-to-one mapping of executables to their output (for instance foo.asp) is a very bad practice. Everytime you change your underlying implementation, URIs will change. However, cool URIs don't change. Julian From w3c-dist-auth-request@w3.org Thu Feb 28 06:07:52 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16798 for ; Thu, 28 Feb 2002 06:07:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA01284; Thu, 28 Feb 2002 06:05:52 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 06:05:52 -0500 (EST) Resent-Message-Id: <200202281105.GAA01284@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 GAA01233 for ; Thu, 28 Feb 2002 06:05:25 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA23881 for ; Thu, 28 Feb 2002 06:05:24 -0500 Received: (qmail 28153 invoked by uid 0); 28 Feb 2002 11:04:51 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp006-rz3) with SMTP; 28 Feb 2002 11:04:51 -0000 From: "Julian Reschke" To: Date: Thu, 28 Feb 2002 12:04:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C1C050.20487260" 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.2600.0000 In-reply-to: <20CF1CE11441D411919C0008C7C5A13B0406340A@stalmail.eu.merant.com> Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5964 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_0009_01C1C050.20487260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: A case for GETSRC (or other mechanism to that effect)Agreed on all points. People interested in defining a replacement for dav:source in a separate draft, please email me :-) -----Original Message----- From: Peter Raymond [mailto:Peter.Raymond@merant.com] Sent: Thursday, February 28, 2002 10:27 AM To: Julian Reschke; Eric Sedlar; w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) Hi, This also surprises me...(see this section from the Salt Lake City IETF meeting minutes.... Getting source code... DAV:source too complex? Take out of 2518, put in it's own spec if people need it. Translate only does 1:1 We took a vote and 4 people were in favour of removing DAV:source, #nobody opposed this. Translate header works well because it's Microsoft and because most servers have one-2-one mapping...eg they edit JSP but not CGI (eg C code) Larry - Why not use a proxy that translates the Translate header into a DAV:source request?? Geoffs objection to translate is that it needs defining for all methods not just a few as it is today. Clients put the translate header on every request if it is working on the source (eg in authoring mode). I seem to remember (and the above enforces this memory) that we took a vote to remove DAV:source from RFC2518 and we agreed. If we fix DAV:source or if we use the Translate header I still think it needs to go into a separate specification for several reasons: - For RFC2518 to move through the standards track we need to show interoperability of this feature and we cannot do that today, we cannot even agree on the best solution - As far as I know we have not seen any clients/servers use the DAV:source property (eg it is not implemented). - I am also interested in managing more than just websites and may need a more advanced way of navigating relationships (perhaps between design documents and the code that implements them or between firmware and circuit board designs etc). This can best be addressed in another specification. Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: 28 February 2002 09:06 To: Eric Sedlar; w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) Eric, that comes as a suprise. As far as I remember the discussion we concluced that: a) the Translate header (or GETSRC) solves only a very specific part of the problem (when there's a one-to-one mapping between source and output), b) the source property needs additional work to become usable, but it's a more generic solution. So as far as I am concerned, the plan was to fix the source property (maybe be taking it out of RFC2518bis and to fix it in a sperate draft). If there were out-of-band discussions, I'd certainly like to hear about it. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Thursday, February 28, 2002 7:19 AM > To: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > Actually, I think Lisa & I convinced Geoff (the big holdout against the > Translate header) to give in at the last IETF meeting. Are there > any other > holdouts with good reason to have a problem with the translate header? > > --Eric > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > > Sent: Wednesday, February 27, 2002 9:59 PM > > To: w3c-dist-auth@w3c.org > > Subject: A case for GETSRC (or other mechanism to that effect) > > > > > > I've been reading the archives, and following the long-running and > > sometimes contentious conversation over retrieval of source > > documents. Maybe bringing this up will get me kicked off the list, > > but we'll see. > > > > First, I appreciate what the DAV working group is trying to do by > > allowing multiple sources for a given document, and making each > > source a separate resource. I won't bother denying that it is useful > > to some people and interesting in its own right. I totally see the > > logic in it. But it is an abstraction that is useful only to a small > > minority of users, and is very difficult to implement. If you doubt > > that, I direct you to the total lack of implementations. But I'll > > make a case on other grounds, as well. > > > > With any DAV request except GET the process is rather straightforward: > > > > A virtual host is selected > > > > Security determines what rights the user has on the URL. In > > the Apache universe that means PUT, POST, MKCOL, GET, etc.. In our > > universe (WebSTAR) that means read, write, list, mkdir, etc.. > > > > We figure out what file the URL maps to. > > > > In deciding which plug-in will handle the request, a DAV > > plug-in simply claims anything with a DAV-specific method. If it is > > MKCOL, DELETE, etc. then the DAV plug-in claims it. > > > > DAV handles the request, within the limits set by the > > security plug-in. > > > > All of this works great, until we get to the GET method. Plug-ins > > have no way of knowing the difference between a normal GET that > > should be handled normally, and a GET that is intended to retrieve > > the source of a document and requires special permissions. In effect > > we have TWO semantics for GET. And so we start creating fake URL > > spaces. But we quickly run into security and configuration hassles. > > > > The bottom line is that there's no way to provide good DAV access > > without some special configuration on the server. And it isn't the > > result of some kind of design error by the implementor, but a basic > > issue with how the protocol is designed. Unless you are only dealing > > with static content you MUST set up a whole new URL space to do DAV > > at all. > > > > In practice setting this up is such a bother that what most > > administrators do is create a whole new virtual host with all > > plug-ins disabled in order to get it done. Is it just me, or is it > > entirely ridiculous that server administrators have to double the > > number of virtual hosts they support just to give decent DAV access > > to their users? > > > > And all of this is so complicated for something that *should* be > > really simple! From most servers' point of view DAV is a way to let > > web authors access their .php, .cgi, .ssi, .shtml, and other dynamic > > files and edit them and save them back onto the server. All of this > > business about an arbitrary number of sources of arbitrary types as > > properties of a single resource don't do our users one bit of good, > > but the implementation is quite burdensome. > > > > What we really need from the DAV protocol is a way to know that a > > given request is intended to retrieve the source of a document, > > without having to also posses knowledge about the DAV configuration, > > or which URL spaces have been quarantined for use exclusively for > > WebDAV, and without having to create special areas in the URL space > > that don't actually map to anything else in the universe just so we > > can turn off all the plug-ins for a few requests. Thus the > > suggestion for a GETSRC property. > > > > I've read the arguments that ask about FINDPROP and other methods > > that act on a resource, and having to double the number of methods to > > support FINDPROP and FINDPROPSRC, etc.. But in most server > > implementations when you get the properties of a .php or .ssi file > > right now, what are you getting? In practice you're getting the > > author and lastmod date and other information about the SOURCE, not > > the output. I don't know of anybody who is executing a .php file and > > then returning the properties of the output -- it (a) isn't practical > > because of all the side-effects it would cause like CPU load and > > errors and code running that you didn't really intend to run and (b) > > isn't useful because nobody cares one whit about the DAV properties > > of PHP output. > > > > I suggest that we just stop considering GET to be a DAV method at > > all. GET has nothing to do with DAV any more than POST does. > > Instead of GET, we should be using GETSRC (or whatever you want to > > call it), always. If you want the output of a source which has been > > run through PHP or SSI or whatever, then fire up your web browser and > > use a GET or POST method. Otherwise, use your DAV client and GETSRC > > (or whatever). > > > > When you work with the properties of a resource, you are working with > > the properties of the resource you receive >from a GETSRC command. > > When you GETSRC, you receive the same data that you PUT. When you > > GET or POST, you receive what the server generates from the source > > and your input. In some cases that happens to be the same as the > > source (static files). > > > > > > If OPTIONS does not indicate that GETSRC is avialable, then a DAV > > client may use GET instead. > > > > Does not preclude a document from having multiple sources at > > different URIs, for the 5% of implementations that need such > > functionality. > > > > Advantages of this approach: > > > > Works well with existing security modules for Apache and > > other servers. Just add GETSRC to the list of methods a user is > > allowed to use. > > > > Provides one semantic for GET (the existing semantic from > > HTTP/1.1 spec) and only one semantic. > > > > Is far more likely to be implemented, and implemented WIDELY, > > than the src property ever will be. > > > > > > This is a major, major problem with the protocol. This is in not an > > indictment of anybody's abilities. Even as a prospective implementor > > reading the spec carefully I didn't appreciate the magnitude of the > > problem until I set out to really implement it, and then it became > > nearly intractable. Even the reference implementation doesn't > > implement it. > > > > The DAV group can take this issue in hand and come up with a solution > > people are willing to implement, or the ad-hoc solutions will become > > de-facto standards. (ie: Translate). Personally, I would rather see > > this solved by the DAV working group. > > > > > > cjh > > > > -- > > > > > ------=_NextPart_000_0009_01C1C050.20487260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A case for GETSRC (or other mechanism to that = effect)
Agreed=20 on all points.
 
People=20 interested in defining a replacement for dav:source in a separate draft, = please=20 email me :-)
-----Original Message-----
From: Peter Raymond=20 [mailto:Peter.Raymond@merant.com]
Sent: Thursday, February = 28, 2002=20 10:27 AM
To: Julian Reschke; Eric Sedlar;=20 w3c-dist-auth@w3c.org
Subject: RE: A case for GETSRC (or = other=20 mechanism to that effect)

Hi,

This also surprises me...(see this section from the = Salt Lake=20 City IETF meeting
minutes.... =


        Getting = source=20 code...

        DAV:source too=20 complex?
        Take out of 2518, put in it's own spec if people need it.=20
        Translate=20 only does 1:1
        = We took a vote and 4 people were in favour of removing = DAV:source,=20
        #nobody=20 opposed this.
        = Translate header works well because it's Microsoft and = because most=20 servers have one-2-one mapping...eg they    edit JSP but not = CGI (eg=20 C code)

        Larry - = Why not use=20 a proxy that translates the Translate header into a DAV:source = request??=20
        Geoffs=20 objection to translate is that it needs defining for all methods not = just a=20 few as it is today. =
       =20 Clients put the translate header on every request if it = is=20 working on the source (eg in authoring mode).

I seem to remember (and the above enforces this = memory) that=20 we took a vote to remove DAV:source
from = RFC2518 and=20 we agreed.  If we fix DAV:source or if we use the Translate = header I=20 still think
it needs to go into a separate=20 specification for several reasons:

- For RFC2518 to move through the standards track we = need to=20 show interoperability of this feature
  = and we=20 cannot do that today, we cannot even agree on the best solution =

- As far as I know we have not seen any = clients/servers use=20 the DAV:source property (eg it is not
  = implemented).

- I am also interested in managing more than just = websites and=20 may need a more advanced way of
  = navigating=20 relationships (perhaps between design documents and the code that = implements=20 them or
  between firmware and circuit = board=20 designs etc).  This can best be addressed in another=20 specification.

Regards,
-- =
Peter Raymond - MERANT
Principal = Architect=20 (PVCS)
Tel: +44 (0)1727 813362 =
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com<= /A>=20
WWW: http://www.merant.com



-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20
Sent: 28 February 2002 09:06
To: Eric=20 Sedlar; w3c-dist-auth@w3c.org
Subject: RE: A = case for=20 GETSRC (or other mechanism to that effect)


Eric,

that comes as a suprise.

As far as I remember the discussion we concluced = that:=20

a) the Translate header (or GETSRC) solves only a = very=20 specific part of the
problem (when there's a = one-to-one mapping between source and output),

b) the source property needs additional work to = become usable,=20 but it's a
more generic solution. =

So as far as I am concerned, the plan was to fix the = source=20 property (maybe
be taking it out of = RFC2518bis and to=20 fix it in a sperate draft).

If there were out-of-band discussions, I'd certainly = like to=20 hear about it.

Julian

> -----Original Message-----
>=20 From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request= @w3.org]On=20 Behalf Of Eric Sedlar
> Sent: Thursday, = February=20 28, 2002 7:19 AM
> To: = w3c-dist-auth@w3c.org=20
> Subject: RE: A case for GETSRC (or other = mechanism to=20 that effect)
>
>=20
> Actually, I think Lisa & I convinced Geoff = (the big=20 holdout against the
> Translate header) = to give in=20 at the last IETF meeting.  Are there
> any=20 other
> holdouts with good reason to have = a problem=20 with the translate header?
> =
> --Eric
>
>=20 > -----Original Message-----
> > = From:=20 w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request= @w3.org]On=20 Behalf Of CJ Holmes
> > Sent: = Wednesday,=20 February 27, 2002 9:59 PM
> > To:=20 w3c-dist-auth@w3c.org
> > Subject: A = case for=20 GETSRC (or other mechanism to that effect)
>=20 >
> >
> > I've=20 been reading the archives, and following the long-running and =
> > sometimes contentious conversation over retrieval = of=20 source
> > documents.  Maybe = bringing this=20 up will get me kicked off the list,
> = > but=20 we'll see.
> >
> >=20 First, I appreciate what the DAV working group is trying to do = by=20
> > allowing multiple sources for a given = document, and=20 making each
> > source a separate=20 resource.  I won't bother denying that it is useful =
> > to some people and interesting in its own = right.  I=20 totally see the
> > logic in it.  = But it is=20 an abstraction that is useful only to a small
>=20 > minority of users, and is very difficult to implement.  If = you=20 doubt
> > that, I direct you to the = total lack=20 of implementations.  But I'll
> > = make a=20 case on other grounds, as well.
> = >=20
> > With any DAV request except GET the = process is=20 rather straightforward:
> > =
> >     A virtual host is = selected=20
> >
> >=20     Security determines what rights the user has on the = URL.  In
> > the Apache universe = that means=20 PUT, POST, MKCOL, GET, etc..  In our
> >=20 universe (WebSTAR) that means read, write, list, mkdir, etc.. =
> >
> > =     We=20 figure out what file the URL maps to.
> = >=20
> >     In deciding which = plug-in will=20 handle the request, a DAV
> > plug-in = simply=20 claims anything with a DAV-specific method.  If it is =
> > MKCOL, DELETE, etc. then the DAV plug-in claims = it.=20
> >
> >=20     DAV handles the request, within the limits set by=20 the
> > security plug-in. =
> >
> > All of this = works great,=20 until we get to the GET method.  Plug-ins
>=20 > have no way of knowing the difference between a normal GET = that=20
> > should be handled normally, and a GET = that is=20 intended to retrieve
> > the source of = a=20 document and requires special permissions.  In effect =
> > we have TWO semantics for GET.  And so we = start creating=20 fake URL
> > spaces.  But we = quickly run=20 into security and configuration hassles.
>=20 >
> > The bottom line is that = there's no way=20 to provide good DAV access
> > without = some=20 special configuration on the server.  And it isn't the =
> > result of some kind of design error by the = implementor, but a=20 basic
> > issue with how the protocol = is=20 designed.  Unless you are only dealing
> >=20 with static content you MUST set up a whole new URL space to do = DAV=20
> > at all.
> = >=20
> > In practice setting this up is such a = bother that=20 what most
> > administrators do is = create a=20 whole new virtual host with all
> > = plug-ins=20 disabled in order to get it done.  Is it just me, or is it =
> > entirely ridiculous that server = administrators have=20 to double the
> > number of virtual = hosts they=20 support just to give decent DAV access
> = > to=20 their users?
> >
>=20 > And all of this is so complicated for something that *should* = be=20
> > really simple!  From most servers' = point of=20 view DAV is a way to let
> > web = authors access=20 their .php, .cgi, .ssi, .shtml, and other dynamic
>=20 > files and edit them and save them back onto the server.  All = of=20 this
> > business about an arbitrary = number of=20 sources of arbitrary types as
> > = properties of=20 a single resource don't do our users one bit of good,
> > but the implementation is quite burdensome. =
> >
> > What we really = need from=20 the DAV protocol is a way to know that a
> >=20 given request is intended to retrieve the source of a document, =
> > without having to also posses knowledge = about the=20 DAV configuration,
> > or which URL = spaces have=20 been quarantined for use exclusively for
> >=20 WebDAV, and without having to create special areas in the URL = space=20
> > that don't actually map to anything else = in the=20 universe just so we
> > can turn off = all the=20 plug-ins for a few requests.  Thus the
> >=20 suggestion for a GETSRC property.
> = >=20
> > I've read the arguments that ask about = FINDPROP and=20 other methods
> > that act on a = resource, and=20 having to double the number of methods to
> >=20 support FINDPROP and FINDPROPSRC, etc..  But in most = server=20
> > implementations when you get the = properties of a=20 .php or .ssi file
> > right now, what = are you=20 getting?  In practice you're getting the
>=20 > author and lastmod date and other information about the SOURCE,=20 not
> > the output.  I don't know = of=20 anybody who is executing a .php file and
> >=20 then returning the properties of the output -- it (a) isn't = practical=20
> > because of all the side-effects it would = cause like=20 CPU load and
> > errors and code = running that=20 you didn't really intend to run and (b)
> = >=20 isn't useful because nobody cares one whit about the DAV = properties=20
> > of PHP output.
>=20 >
> > I suggest that we just stop = considering=20 GET to be a DAV method at
> > = all.  GET has=20 nothing to do with DAV any more than POST does.
>=20 > Instead of GET, we should be using GETSRC (or whatever you want = to=20
> > call it), always.  If you want the = output of a=20 source which has been
> > run through = PHP or SSI=20 or whatever, then fire up your web browser and
>=20 > use a GET or POST method.  Otherwise, use your DAV client = and=20 GETSRC
> > (or whatever). =
> >
> > When you work = with the=20 properties of a resource, you are working with
>=20 > the properties of the resource you receive >from a GETSRC=20 command.
> > When you GETSRC, you = receive the=20 same data that you PUT.  When you
> = > GET=20 or POST, you receive what the server generates from the source=20
> > and your input.  In some cases that = happens to=20 be the same as the
> > source (static=20 files).
> >
>=20 >
> > If OPTIONS does not indicate = that=20 GETSRC is avialable, then a DAV
> > = client may=20 use GET instead.
> >
> > Does not preclude a document from having multiple = sources=20 at
> > different URIs, for the 5% of=20 implementations that need such
> >=20 functionality.
> >
>=20 > Advantages of this approach:
> = >=20
> >     Works well with = existing=20 security modules for Apache and
> > = other=20 servers.  Just add GETSRC to the list of methods a user is =
> > allowed to use.
>=20 >
> >     Provides = one=20 semantic for GET (the existing semantic from
> >=20 HTTP/1.1 spec) and only one semantic.
> = >=20
> >     Is far more likely to = be=20 implemented, and implemented WIDELY,
> = > than=20 the src property ever will be.
> = >=20
> >
> > This = is a major,=20 major problem with the protocol.  This is in not an =
> > indictment of anybody's abilities.  Even as a=20 prospective implementor
> > reading = the spec=20 carefully I didn't appreciate the magnitude of the
> > problem until I set out to really implement it, and = then it=20 became
> > nearly intractable.  = Even the=20 reference implementation doesn't
> > = implement=20 it.
> >
> = > The=20 DAV group can take this issue in hand and come up with a = solution=20
> > people are willing to implement, or the = ad-hoc=20 solutions will become
> > de-facto=20 standards.  (ie: Translate).  Personally, I would rather = see=20
> > this solved by the DAV working = group.=20
> >
> = >
> > cjh
> > =
> > --
> > =
> >
>=20

------=_NextPart_000_0009_01C1C050.20487260-- From w3c-dist-auth-request@w3.org Thu Feb 28 06:13:44 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16865 for ; Thu, 28 Feb 2002 06:13:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA02105; Thu, 28 Feb 2002 06:12:47 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 06:12:47 -0500 (EST) Resent-Message-Id: <200202281112.GAA02105@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 GAA02070 for ; Thu, 28 Feb 2002 06:12:22 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA24818 for ; Thu, 28 Feb 2002 06:12:22 -0500 Received: (qmail 19380 invoked by uid 0); 28 Feb 2002 11:11:51 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 28 Feb 2002 11:11:51 -0000 From: "Julian Reschke" To: Date: Thu, 28 Feb 2002 12:11:51 +0100 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.2600.0000 In-reply-to: Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5965 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 Eric Sedlar >Sent: Thursday, February 28, 2002 10:43 AM >To: Peter Raymond; Julian Reschke; w3c-dist-auth@w3c.org >Subject: RE: A case for GETSRC (or other mechanism to that effect) > > >Comments inlined... To all: please do not post in HTML. It makes commenting hard, and it breaks the web archive. >The proposal would be that Translate: F would only have an effect on the GET method, and could be either ignored or forbidden on other methods ( one of the nits that Geoff picked at >at the dinner where we won him over)... I see. I guess he dind't have to pay his bill either :-) >There is certainly interoperability for Translate: F, so I don't see why that needs to go into a separate spec. It's not defined in RFC2518, so it can't easily be put into it's revision. If you want to put it in, you'll have to get agreement on lots of issues (some of which we already discussed). As there currently is *no* technical documentation about the Translate header, it will be hard to get proper definitions of it's semantics (saying: "whatever Frontpage does" doesn't count). >>- I am also interested in managing more than just websites and may need a more advanced way of >> navigating relationships (perhaps between design documents and the code that implements them or >> between firmware and circuit board designs etc). This can best be addressed in another specification. >The issue of how the executable is generated is a separate question from getting at the executable content itself (see my reply to Julian's email). >Regards, I think you currently consider only a few special use cases. DAV:source was designed to address a more generic problem. I think it can be fixed, and we should try this. From w3c-dist-auth-request@w3.org Thu Feb 28 06:23:28 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16950 for ; Thu, 28 Feb 2002 06:23:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA02599; Thu, 28 Feb 2002 06:22:27 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 06:22:27 -0500 (EST) Resent-Message-Id: <200202281122.GAA02599@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 GAA02565 for ; Thu, 28 Feb 2002 06:22:01 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA26112 for ; Thu, 28 Feb 2002 06:22:01 -0500 Received: (qmail 29592 invoked by uid 0); 28 Feb 2002 11:21:30 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 28 Feb 2002 11:21:30 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Thu, 28 Feb 2002 12:21:30 +0100 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.2600.0000 In-reply-to: Subject: RE: RFC2518bis: allprop deprecated (4.1) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5966 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 Following up to my own post: the last WG meeting minutes (at ) say: "What 'allprop' means.... MUST include all 2518 props and all dead props to maintain interrop. However new live props in ACL DASL etc are being defined as NOT returned by allprop. Property dead on one server may not be dead on another server. allprop is historical. Promote using propname. Is it legal for Xythos to use the adobe namespace? You could have a property that is defined dead on one server be live on another! allprop must return all properties required for interrop. Eric - property should be defined dead or non-nead...you can't mix and match. Should we deprecate allprop? Perhaps use allprop-include or other mechanism to save roundtrip and deprecate allprop. Sitecopy properties would not be the same. Is deprecate something we can do in IETF? Take it out and reference them back to the old draft. Geoff - Short description plus reference back to old spec. We took a vote and 3 people would like it to become a info note, nobody objected." I'm not sure I understand what the last paragraph says. I certainly do *not* agree to remove allprop without replacing it with something which is as efficient. See remarks in my previous mail. Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Thursday, February 21, 2002 9:52 AM > To: Lisa Dusseault; Webdav WG > Subject: RFC2518bis: allprop deprecated (4.1) > > > Lisa, > > I don't agree at all with the deprecation, and I don't think that > there was > consensus about this. > > The draft says: > > Clients MUST not send allprop requests in any form (either the empty body > PROPFIND or the specific allprop element), because allprop is > being removed. > WebDAV servers increasingly have expensively-calculated or lengthy > properties (see DeltaV and ACL specifications [TODO: ref RFC when > available]) and do not return all properties already. Instead, WebDAV > clients can use propname requests to discover what properties exist, and > request named properties when retrieving values. A WebDAV server MAY omit > certain live properties from other specifications when responding to an > allprop request from an older client, and MAY return only custom (dead) > properties and those defined in this specification. > > In particular: > > "WebDAV servers increasingly have expensively-calculated or lengthy > properties (see DeltaV and ACL specifications [TODO: ref RFC when > available]) and do not return all properties already." > > -> This is an argument for *restricting* the set of properties returned on > allprop, not for removing the feature (and that's what deltaV does). > > "Instead, WebDAV clients can use propname requests to discover what > properties exist, and request named properties when retrieving values." > > -> And the benefit is? The client will issue two calls: first it will use > propname to find the list of properties. Computing whether a live property > exists maybe as expensive as computing it (for instance, to find > out whether > something is checked in/out). *Then* it will submit PROPFIND / > prop will all > these properties. So as compared to the current situation, the server may > have to compute things twice which wouldn't have been computed at > all before > (since asking for allprop wouldn't require computing live deltaV > properties). > > -> Even leaving the propname vs live properties issue out, this > doesn't make > sense. You are removing a working and interoperable protocol > feature without > sound reason. As a fallback you offer a workaround which requires at least > one additional trip to the server, possibly heavy computation on > the client > (computing the set of all property names on the members of a > collection) and > then additional marshalling (when I do a PROPFIND/prop with a long list of > (dead) property names on a collection with depth 1, the server > will have to > 404-status them for many collection members). > > -> I agree that PROPFIND needs to be cleaned up, but this is not > the way to > go. The draft continues with: > > "A WebDAV server MAY omit certain live properties from other > specifications > when responding to an allprop request from an older client, and MAY return > only custom (dead) properties and those defined in this specification." > > -> I think this may make sense. We will however need a way to get all dead > properties and a set of named properties with a single request > (see [1]). We > may also have to find a way for a client to discover that something is a > live property. > > > [1] > From w3c-dist-auth-request@w3.org Thu Feb 28 09:06:41 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23572 for ; Thu, 28 Feb 2002 09:06:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA11987; Thu, 28 Feb 2002 09:05:17 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 09:05:17 -0500 (EST) Resent-Message-Id: <200202281405.JAA11987@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 JAA11963 for ; Thu, 28 Feb 2002 09:04:58 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA17031 for ; Thu, 28 Feb 2002 09:04:58 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Thu, 28 Feb 2002 09:03:02 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 09:04:26 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105F848E2@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 28 Feb 2002 09:04:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5967 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: As I recall, I was willing to consider the Translate header or a GETSRC method, if I was the only one who found them objectionable. I consider a separate URL space for authoring a superior approach, since I believe separate URL spaces are a simpler model, and one that will prove to be more extensible. It also is very compatible with common web server extension mechanisms, which allow you to dispatch to different modules based on what part of the URL space you are operating in. So with support from Julian, it no longer is "just me", so I revert to my natural position, which is against both the Translate header or a GETSRC method. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, February 28, 2002 6:12 AM To: w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) >From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar >Sent: Thursday, February 28, 2002 10:43 AM >To: Peter Raymond; Julian Reschke; w3c-dist-auth@w3c.org >Subject: RE: A case for GETSRC (or other mechanism to that effect) > > >Comments inlined... To all: please do not post in HTML. It makes commenting hard, and it breaks the web archive. >The proposal would be that Translate: F would only have an effect on the GET method, and could be either ignored or forbidden on other methods ( one of the nits that Geoff picked at >at the dinner where we won him over)... I see. I guess he dind't have to pay his bill either :-) >There is certainly interoperability for Translate: F, so I don't see why that needs to go into a separate spec. It's not defined in RFC2518, so it can't easily be put into it's revision. If you want to put it in, you'll have to get agreement on lots of issues (some of which we already discussed). As there currently is *no* technical documentation about the Translate header, it will be hard to get proper definitions of it's semantics (saying: "whatever Frontpage does" doesn't count). >>- I am also interested in managing more than just websites and may need a more advanced way of >> navigating relationships (perhaps between design documents and the code that implements them or >> between firmware and circuit board designs etc). This can best be addressed in another specification. >The issue of how the executable is generated is a separate question from getting at the executable content itself (see my reply to Julian's email). >Regards, I think you currently consider only a few special use cases. DAV:source was designed to address a more generic problem. I think it can be fixed, and we should try this. From w3c-dist-auth-request@w3.org Thu Feb 28 09:41:19 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25402 for ; Thu, 28 Feb 2002 09:41:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16124; Thu, 28 Feb 2002 09:40:10 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 09:40:10 -0500 (EST) Resent-Message-Id: <200202281440.JAA16124@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 JAA16089 for ; Thu, 28 Feb 2002 09:39:49 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA25278 for ; Thu, 28 Feb 2002 09:39:49 -0500 Received: (qmail 12169 invoked by uid 0); 28 Feb 2002 14:39:18 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 28 Feb 2002 14:39:18 -0000 From: "Julian Reschke" To: Date: Thu, 28 Feb 2002 15:39:18 +0100 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.2600.0000 In-reply-to: <3906C56A7BD1F54593344C05BD1374B105F848E2@SUS-MA1IT01> Subject: RFC2518 issue: DAV:href format Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5968 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 See . RFC2518 says that the contents of DAV:href is a URI as defined by RFC2068 (which should be updated to refer to RFC2396). The spec seems to be consistent with this (all examples include protocol and authority). However, Apache moddav only returns relative URI references (protocol and authority are missing), so technically doesn't return URIs at all. Microsoft IIS returns correct URIs. All clients seem to be happy with both. So, 1) either Apache moddav should be fixed, or 2) RFC2518 should allow relative URI references. *If* we go with 2), the spec will have to define which base URI needs to be used to resolve the URI reference to a full URI (the request URI comes to mind). Note that this would allow new kinds of PROPFIND responses that *will* not interoperate with many clients: PROPFIND /foo/bar Depth: 1 .. ... child-of-bar .. (This could be avoided by saying that the base URI *always* is "://:/"). From w3c-dist-auth-request@w3.org Thu Feb 28 10:19:03 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27797 for ; Thu, 28 Feb 2002 10:19:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA17960; Thu, 28 Feb 2002 10:17:06 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 10:17:06 -0500 (EST) Resent-Message-Id: <200202281517.KAA17960@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 KAA17920 for ; Thu, 28 Feb 2002 10:16:49 -0500 (EST) 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 KAA32337 for ; Thu, 28 Feb 2002 10:16:49 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA104776 for ; Thu, 28 Feb 2002 09:11:37 -0600 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.117.200.72]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1SFGEg89506 for ; Thu, 28 Feb 2002 10:16:15 -0500 To: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 28 Feb 2002 09:54:36 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 02/28/2002 10:16:14 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5969 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 in favor of DAV:source and agree it needs work and can accept it going in a seperate spec. This need not be to the exclusion of another option. My priority is in getting 2518 updated, but I'd be eager to take part in the discussion of DAV:source and it's alternatives. I think it's an important issue. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Feb 28 10:48:25 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29454 for ; Thu, 28 Feb 2002 10:48:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA23388; Thu, 28 Feb 2002 10:47:27 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 10:47:27 -0500 (EST) Resent-Message-Id: <200202281547.KAA23388@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 KAA23115 for ; Thu, 28 Feb 2002 10:47:05 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA07479 for ; Thu, 28 Feb 2002 10:47:05 -0500 Received: (qmail 602 invoked by uid 0); 28 Feb 2002 15:46:34 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 28 Feb 2002 15:46:34 -0000 From: "Julian Reschke" To: "WebDAV" Date: Thu, 28 Feb 2002 16:46:33 +0100 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.2600.0000 In-reply-to: Subject: RE: Features of WEBDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5970 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 Jim Whitehead > Sent: Wednesday, February 27, 2002 7:04 AM > To: WebDAV > Cc: schreiber@massive.de > Subject: RE: Features of WEBDAV > > .. > > Advanced collections work is currently on hold. After ACLs, the next major > piece of work will be completing the DASL specification. DASL is looking > like it will be finished in late 2002. Maybe :-) It would certainly help if there would be more feedback on the DASL mailing list [1]. The current SEARCH draft has been updated a few minutes ago [2]. [1] [2] From w3c-dist-auth-request@w3.org Thu Feb 28 12:30:14 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06821 for ; Thu, 28 Feb 2002 12:30:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10878; Thu, 28 Feb 2002 12:28:29 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 12:28:29 -0500 (EST) Resent-Message-Id: <200202281728.MAA10878@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 MAA10814 for ; Thu, 28 Feb 2002 12:28:05 -0500 (EST) Received: from stlouis.day.com (64-60-92-50-cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA30470; Thu, 28 Feb 2002 12:28:05 -0500 From: phillip.lindsay@day.com Received: from us-mail.day.com (us-mail.day.com [10.2.8.5]) by stlouis.day.com (8.12.1/8.12.1) with ESMTP id g1SHQdai024163; Thu, 28 Feb 2002 09:26:39 -0800 (PST) To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org, w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Thu, 28 Feb 2002 09:24:53 -0800 X-MIMETrack: Serialize by Router on us-mail/Day(Release 5.0.8 |June 18, 2001) at 02/28/2002 09:24:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5971 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 think a fundamental web architecture issue is being ignored if we simply look at URL space as a functional categorization. IMHO, it should be viewed as a means for classification (as originally intended) of information, and thus humans should be able to find resources given an information architecture. If we assume a separate/distinct namespace is a requirement, we throw away the ability to maintain a valuable abstraction. There is precedence in presentation of information given context (.e.g., role) and making DAV:source work would satisfy this. Phillip A. Lindsay (phillip.lindsay@day.com) Principal Architect Day Software, Inc. "Clemm, Geoff" cc: Sent by: Subject: RE: A case for GETSRC (or other mechanism to that effect) w3c-dist-auth-requ est@w3.org 02/28/2002 06:04 AM As I recall, I was willing to consider the Translate header or a GETSRC method, if I was the only one who found them objectionable. I consider a separate URL space for authoring a superior approach, since I believe separate URL spaces are a simpler model, and one that will prove to be more extensible. It also is very compatible with common web server extension mechanisms, which allow you to dispatch to different modules based on what part of the URL space you are operating in. So with support from Julian, it no longer is "just me", so I revert to my natural position, which is against both the Translate header or a GETSRC method. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, February 28, 2002 6:12 AM To: w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) >From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar >Sent: Thursday, February 28, 2002 10:43 AM >To: Peter Raymond; Julian Reschke; w3c-dist-auth@w3c.org >Subject: RE: A case for GETSRC (or other mechanism to that effect) > > >Comments inlined... To all: please do not post in HTML. It makes commenting hard, and it breaks the web archive. >The proposal would be that Translate: F would only have an effect on the GET method, and could be either ignored or forbidden on other methods ( one of the nits that Geoff picked at >at the dinner where we won him over)... I see. I guess he dind't have to pay his bill either :-) >There is certainly interoperability for Translate: F, so I don't see why that needs to go into a separate spec. It's not defined in RFC2518, so it can't easily be put into it's revision. If you want to put it in, you'll have to get agreement on lots of issues (some of which we already discussed). As there currently is *no* technical documentation about the Translate header, it will be hard to get proper definitions of it's semantics (saying: "whatever Frontpage does" doesn't count). >>- I am also interested in managing more than just websites and may need a more advanced way of >> navigating relationships (perhaps between design documents and the code that implements them or >> between firmware and circuit board designs etc). This can best be addressed in another specification. >The issue of how the executable is generated is a separate question from getting at the executable content itself (see my reply to Julian's email). >Regards, I think you currently consider only a few special use cases. DAV:source was designed to address a more generic problem. I think it can be fixed, and we should try this. From w3c-dist-auth-request@w3.org Thu Feb 28 12:35:55 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07179 for ; Thu, 28 Feb 2002 12:35:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA12083; Thu, 28 Feb 2002 12:34:32 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 12:34:32 -0500 (EST) Resent-Message-Id: <200202281734.MAA12083@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 MAA11896 for ; Thu, 28 Feb 2002 12:34:04 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA31388 for ; Thu, 28 Feb 2002 12:34:04 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Thu, 28 Feb 2002 12:32:09 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 12:33:33 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AFD6@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 28 Feb 2002 12:33:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5972 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 counter argument is that the URL space is demonstrably a very poor mechanism for searching and classifying information, thus the introduction of search engines, and protocols like WebDAV that introduce "properties" that allow you to declare the information needed for content and keyword based searches and classification. That is one of the reasons why it is preferable for the "source" and the "result" be distinct resources (with distinct URL's), so that the property mechanism can be used to locate either the source or the result, depending on what you are interested in. Cheers, Geoff -----Original Message----- From: phillip.lindsay@day.com [mailto:phillip.lindsay@day.com] Sent: Thursday, February 28, 2002 12:25 PM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org; w3c-dist-auth-request@w3.org Subject: RE: A case for GETSRC (or other mechanism to that effect) I think a fundamental web architecture issue is being ignored if we simply look at URL space as a functional categorization. IMHO, it should be viewed as a means for classification (as originally intended) of information, and thus humans should be able to find resources given an information architecture. If we assume a separate/distinct namespace is a requirement, we throw away the ability to maintain a valuable abstraction. There is precedence in presentation of information given context (.e.g., role) and making DAV:source work would satisfy this. Phillip A. Lindsay (phillip.lindsay@day.com) Principal Architect Day Software, Inc. "Clemm, Geoff" cc: Sent by: Subject: RE: A case for GETSRC (or other mechanism to that effect) w3c-dist-auth-requ est@w3.org 02/28/2002 06:04 AM As I recall, I was willing to consider the Translate header or a GETSRC method, if I was the only one who found them objectionable. I consider a separate URL space for authoring a superior approach, since I believe separate URL spaces are a simpler model, and one that will prove to be more extensible. It also is very compatible with common web server extension mechanisms, which allow you to dispatch to different modules based on what part of the URL space you are operating in. So with support from Julian, it no longer is "just me", so I revert to my natural position, which is against both the Translate header or a GETSRC method. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, February 28, 2002 6:12 AM To: w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) >From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar >Sent: Thursday, February 28, 2002 10:43 AM >To: Peter Raymond; Julian Reschke; w3c-dist-auth@w3c.org >Subject: RE: A case for GETSRC (or other mechanism to that effect) > > >Comments inlined... To all: please do not post in HTML. It makes commenting hard, and it breaks the web archive. >The proposal would be that Translate: F would only have an effect on the GET method, and could be either ignored or forbidden on other methods ( one of the nits that Geoff picked at >at the dinner where we won him over)... I see. I guess he dind't have to pay his bill either :-) >There is certainly interoperability for Translate: F, so I don't see why that needs to go into a separate spec. It's not defined in RFC2518, so it can't easily be put into it's revision. If you want to put it in, you'll have to get agreement on lots of issues (some of which we already discussed). As there currently is *no* technical documentation about the Translate header, it will be hard to get proper definitions of it's semantics (saying: "whatever Frontpage does" doesn't count). >>- I am also interested in managing more than just websites and may need a more advanced way of >> navigating relationships (perhaps between design documents and the code that implements them or >> between firmware and circuit board designs etc). This can best be addressed in another specification. >The issue of how the executable is generated is a separate question from getting at the executable content itself (see my reply to Julian's email). >Regards, I think you currently consider only a few special use cases. DAV:source was designed to address a more generic problem. I think it can be fixed, and we should try this. From w3c-dist-auth-request@w3.org Thu Feb 28 12:45:55 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07918 for ; Thu, 28 Feb 2002 12:45:55 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13368; Thu, 28 Feb 2002 12:45:01 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 12:45:01 -0500 (EST) Resent-Message-Id: <200202281745.MAA13368@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 MAA13339 for ; Thu, 28 Feb 2002 12:44:39 -0500 (EST) Received: from rgminet1.oracle.com (rgminet1.oracle.com [148.87.122.30]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA32664 for ; Thu, 28 Feb 2002 12:44:38 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by rgminet1.oracle.com (Switch-2.1.4/Switch-2.1.0) with ESMTP id g1SHm2V03614; Thu, 28 Feb 2002 10:48:02 -0700 (MST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g1SHibI21760; Thu, 28 Feb 2002 10:44:37 -0700 (MST) From: "Eric Sedlar" To: "Julian Reschke" , Date: Thu, 28 Feb 2002 09:44:31 -0800 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5973 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----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Thursday, February 28, 2002 2:59 AM > To: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > > Sent: Thursday, February 28, 2002 10:25 AM > > To: Julian Reschke; w3c-dist-auth@w3c.org > > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > > > > I think the point is that for every method other than GET, the method > > operates on a particular source object, not a set of them. > dav:source is > > actually trying to track one level beyond that. Translate: F, or > > GETSRC, is > > just trying to get back the same contents that were PUT to that > location. > > Actually, with dav:source and multiple URIs PUTting to the > non-source result > would result in an error (or at least wouldn't have any effect at all). > > > The only time Translate/GETSRC is relevant is for executables (cgi's, > > servlets, etc.) at a particular URL which generate some dynamic content. > > I don't agree. DAV:source may be relevant for "compiled" > resources as well. > For instance, static HTML might be generated by a one-time compilation > process, but you don't want anybody to *modify* the HTML. Rather, people > would need to be pointed to the modifiable source (for instance, XML and > XSLT input files). > My point is not that dav:source is relevant (it is clearly useful to look at the source files as in your example), but whether or not it is useful (three years of industry experience say clearly it is not) is irrelevant to whether or not Translate/GETSRC is useful. You have pointed out a case (like regular files) where GET and GETSRC would return the same result. Whether or not you want to allow people to directly write to compiled output (or an executable) is a separate issue (which could be handled via an ACL, or the server could generate an error). > > So, there are really three different sets of content we are looking at: > > > > 1) the generated output returned by GET > > > > 2) the executable that generates the content for GET, and > which is the > > object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK, > > MOVE, COPY, > > ...) > > I don't think I agree. PROPFIND etc. should access the same > resource as GET > (if they are applied to the same URI). > > > 3) the multiple source files that were used to generate the > executable > > > > > > The GET method returns resource #1, dav:source (if it were actually > > implemented by anyone) would list #3. Translate: F, or GETSRC, returns > > resource #2, which is the one logically consistent with the other WebDAV > > methods. > > Yes, but dav:source can do this for you as well. Why have two different > models if one is enough? > dav:source deals with a completely separate use case. I clearly need to separate out the executable at the current URL from the files that generate it. In the case of a compiled executable, would you recommend putting both the executable URL and the .o's & .c's that generate it in the same undifferentiated dav:source bucket? It's clearly necessary to separate the two sets of things, for the case when you can directly PUT to the executable resource. > > Actually figuring out #3 is something the equivalent of makefile > > dependency > > tracking, and is not generally available even in a development > > environment, > > which is something that WebDAV is certainly not. > > That would only be a problem if WebDAV required that the list of > sources is > exhaustive. It doesn't. It's just a hint to a client where to > look for files > that actually *affect* the resource when edited. > > > Real-world experience has shown that: > > > > * nobody actually tracks multiple source files for an executable > > * people sometimes want to actually get the executable contents > > > > Nobody has actually come up with a real-world use-case for > dav:source, but > > whether or not dav:source is deprecated or not, it's actually > > identifying a > > different set of content than Translate: F / GETSRC. > > I disagree. Could you please explain why the model used in > DAV:source can't > be applied to this use case? > You disagree? Can you point to any implementations that actually keep track of the source files? I'm not saying you can't make up an example, just that in practice, servers don't keep track of the references to the source. > > And, once you realize that you need Translate: F or GETSRC, you might as > > well use Translate: F, as you will have no problem getting interoperable > > implementations, and it is functionally equivalent to GETSRC. > > Using the same URI for "the" source (assuming there is only one) and the > output means that you can't point people explicitly to one of > them. As user > agents generally aren't aware of the Translate header (or GETSRC), they > would fetch the output resource, so basically you have a source resource > which you can't refer to. > So you are using the existing practice argument? Existing user agents aren't aware of dav:source either, so in any case we are talking about new functionality. > Actually, having a one-to-one mapping of executables to their output (for > instance foo.asp) is a very bad practice. Everytime you change your > underlying implementation, URIs will change. However, cool URIs don't > change. > What URIs are you talking about? Can you give an example of this? Clearly there is widespread industry support for the one-to-one mapping you describe (cgi, .asp). --Eric From w3c-dist-auth-request@w3.org Thu Feb 28 13:02:05 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09065 for ; Thu, 28 Feb 2002 13:02:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15272; Thu, 28 Feb 2002 13:00:47 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 13:00:47 -0500 (EST) Resent-Message-Id: <200202281800.NAA15272@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 NAA15237 for ; Thu, 28 Feb 2002 13:00:27 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA02538 for ; Thu, 28 Feb 2002 13:00:27 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Thu, 28 Feb 2002 12:58:30 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 12:59:54 -0500 Message-ID: <982A819715AC804D915E8A053B48CBB802AC9604@sus-ma1it04.rational.com> From: "Vasta, John" To: "'Julian Reschke'" , w3c-dist-auth@w3c.org Date: Thu, 28 Feb 2002 12:59:53 -0500 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: DAV:href format Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5974 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: The specific reference in RFC2518 is to the definition of "URI" in section 3.2.1 in RFC2068, which corresponds to the definition of "URI-reference" in section 4 of RFC2396. In both places, the definition is [ absoluteURI | relativeURI ] [ '#' fragment ] which seems clear to me that the content of a DAV:href element can be either an absolute or relative URI. Also, as an implementor of a mod_dav "repository provider", I can say that it would be difficult to construct absolute URI's in the layer of code which generates DAV:href elements, since that layer has no access to the Apache request info needed to construct an absolute URI. So relative URI's are desirable, both from an implementor's standpoint, and from the fact that they reduce message size somewhat. From the above definitions, RFC2518 clearly allows relative URI's in DAV:href elements. I agree that it should be clarified what the base URI is; since all the clients I've looked at assume it is the request URI, then that seems like the right thing to say. John > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, February 28, 2002 9:39 AM > To: w3c-dist-auth@w3c.org > Subject: RFC2518 issue: DAV:href format > > > See . > > RFC2518 says that the contents of DAV:href is a URI as > defined by RFC2068 > (which should be updated to refer to RFC2396). > > The spec seems to be consistent with this (all examples > include protocol and > authority). > > However, Apache moddav only returns relative URI references > (protocol and > authority are missing), so technically doesn't return URIs at > all. Microsoft > IIS returns correct URIs. All clients seem to be happy with both. > > So, > > 1) either Apache moddav should be fixed, or > 2) RFC2518 should allow relative URI references. > > *If* we go with 2), the spec will have to define which base > URI needs to be > used to resolve the URI reference to a full URI (the request > URI comes to > mind). Note that this would allow new kinds of PROPFIND responses that > *will* not interoperate with many clients: > > PROPFIND /foo/bar > Depth: 1 > > .. > > > > > ... > > > child-of-bar > .. > > > > > (This could be avoided by saying that the base URI *always* is > "://:/"). > > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 28 13:39:38 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11472 for ; Thu, 28 Feb 2002 13:39:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA18932; Thu, 28 Feb 2002 13:37:28 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 13:37:28 -0500 (EST) Resent-Message-Id: <200202281837.NAA18932@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 NAA18898 for ; Thu, 28 Feb 2002 13:37:04 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA07312 for ; Thu, 28 Feb 2002 13:37:03 -0500 Received: (qmail 492 invoked by uid 0); 28 Feb 2002 18:36:32 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp014-rz3) with SMTP; 28 Feb 2002 18:36:32 -0000 From: "Julian Reschke" To: Date: Thu, 28 Feb 2002 19:36:30 +0100 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <982A819715AC804D915E8A053B48CBB802AC9604@sus-ma1it04.rational.com> Subject: RE: RFC2518 issue: DAV:href format Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5975 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 Vasta, John > Sent: Thursday, February 28, 2002 7:00 PM > To: 'Julian Reschke'; w3c-dist-auth@w3c.org > Subject: RE: RFC2518 issue: DAV:href format > > > The specific reference in RFC2518 is to the definition of "URI" in section > 3.2.1 in RFC2068, which corresponds to the definition of > "URI-reference" in > section 4 of RFC2396. In both places, the definition is > > [ absoluteURI | relativeURI ] [ '#' fragment ] > > which seems clear to me that the content of a DAV:href element > can be either > an absolute or relative URI. Indeed. I got confused by the usage of "URI". So we still need to update RFC2518: a) refer to the current RFC, b) don't use the term URI when what is meant is a "URI reference". c) clarify what the base URI for resolving a relative URI reference is. > Also, as an implementor of a mod_dav "repository provider", I can say that > it would be difficult to construct absolute URI's in the layer of > code which > generates DAV:href elements, since that layer has no access to the Apache > request info needed to construct an absolute URI. > > So relative URI's are desirable, both from an implementor's > standpoint, and > >from the fact that they reduce message size somewhat. From the above > definitions, RFC2518 clearly allows relative URI's in DAV:href elements. I > agree that it should be clarified what the base URI is; since all the > clients I've looked at assume it is the request URI, then that seems like > the right thing to say. > > John > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Thursday, February 28, 2002 9:39 AM > > To: w3c-dist-auth@w3c.org > > Subject: RFC2518 issue: DAV:href format > > > > > > See . > > > > RFC2518 says that the contents of DAV:href is a URI as > > defined by RFC2068 > > (which should be updated to refer to RFC2396). > > > > The spec seems to be consistent with this (all examples > > include protocol and > > authority). > > > > However, Apache moddav only returns relative URI references > > (protocol and > > authority are missing), so technically doesn't return URIs at > > all. Microsoft > > IIS returns correct URIs. All clients seem to be happy with both. > > > > So, > > > > 1) either Apache moddav should be fixed, or > > 2) RFC2518 should allow relative URI references. > > > > *If* we go with 2), the spec will have to define which base > > URI needs to be > > used to resolve the URI reference to a full URI (the request > > URI comes to > > mind). Note that this would allow new kinds of PROPFIND responses that > > *will* not interoperate with many clients: > > > > PROPFIND /foo/bar > > Depth: 1 > > > > .. > > > > > > > > > > ... > > > > > > child-of-bar > > .. > > > > > > > > > > (This could be avoided by saying that the base URI *always* is > > "://:/"). > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 28 13:58:40 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12839 for ; Thu, 28 Feb 2002 13:58:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA20309; Thu, 28 Feb 2002 13:56:36 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 13:56:36 -0500 (EST) Resent-Message-Id: <200202281856.NAA20309@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 NAA20261 for ; Thu, 28 Feb 2002 13:56:11 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA09664 for ; Thu, 28 Feb 2002 13:56:11 -0500 Received: (qmail 5964 invoked by uid 0); 28 Feb 2002 18:55:39 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp007-rz3) with SMTP; 28 Feb 2002 18:55:39 -0000 From: "Julian Reschke" To: Date: Thu, 28 Feb 2002 19:55:37 +0100 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 V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5976 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 only time Translate/GETSRC is relevant is for executables (cgi's, > > > servlets, etc.) at a particular URL which generate some > dynamic content. > > > > I don't agree. DAV:source may be relevant for "compiled" > > resources as well. > > For instance, static HTML might be generated by a one-time compilation > > process, but you don't want anybody to *modify* the HTML. Rather, people > > would need to be pointed to the modifiable source (for instance, XML and > > XSLT input files). > > > > My point is not that dav:source is relevant (it is clearly useful > to look at > the source files as in your example), but whether or not it is > useful (three > years of industry experience say clearly it is not) is irrelevant I disagree. The way it's spec'd is broken. Not the generic concept. > to whether > or not Translate/GETSRC is useful. You have pointed out a case (like > regular files) where GET and GETSRC would return the same result. Whether > or not you want to allow people to directly write to compiled > output (or an > executable) is a separate issue (which could be handled via an ACL, or the > server could generate an error). The example I gave was not about *forbidding* the modification, it was about allowing the user agent to *discover* the files on which this compiled/generated file is based (so it can offer to edit *those* instead). > ... > > dav:source deals with a completely separate use case. I clearly need to > separate out the executable at the current URL from the files > that generate Sure. > it. In the case of a compiled executable, would you recommend > putting both > the executable URL and the .o's & .c's that generate it in the same > undifferentiated dav:source bucket? It's clearly necessary to > separate the > two sets of things, for the case when you can directly PUT to the > executable > resource. Yes. So? For instance, the source property for an executable might contain hrefs to C sources and a Makefile. What I'm saying is that the executable and it's output are different resources (not different representations of the same resource) and thus should have different URIs. So, if we would have the URIs a) /sources/hello-world.c b) /sources/Makefile c) /bin/a.out d) /greeting then c) would have the sources a) and b), while d) has the source c). > .. > > > > Real-world experience has shown that: > > > > > > * nobody actually tracks multiple source files for an executable > > > * people sometimes want to actually get the executable contents > > > > > > Nobody has actually come up with a real-world use-case for > > dav:source, but > > > whether or not dav:source is deprecated or not, it's actually > > > identifying a > > > different set of content than Translate: F / GETSRC. > > > > I disagree. Could you please explain why the model used in > > DAV:source can't > > be applied to this use case? > > > > You disagree? Can you point to any implementations that actually > keep track > of the source files? I'm not saying you can't make up an > example, just that > in practice, servers don't keep track of the references to the source. To take the popular use case (IIS and ASP files): an ASP file generates HTML output, so the source property of the HTML output resource should/can point to the ASP resource. Just because Microsoft decided a few years ago that keeping both the output and the script at the same URI (for Frontpage) doesn't make this the only possible approach. Generelly, if a server doesn't know the source (or only some of them), or if it doesn't want to expose them, that's fine. It's just a pointer for a user agent where to find the editable source(s). > > > And, once you realize that you need Translate: F or GETSRC, > you might as > > > well use Translate: F, as you will have no problem getting > interoperable > > > implementations, and it is functionally equivalent to GETSRC. > > > > Using the same URI for "the" source (assuming there is only one) and the > > output means that you can't point people explicitly to one of > > them. As user > > agents generally aren't aware of the Translate header (or GETSRC), they > > would fetch the output resource, so basically you have a source resource > > which you can't refer to. > > > > So you are using the existing practice argument? Existing user agents > aren't aware of dav:source either, so in any case we are talking about new > functionality. I was saying that we really don't have interoperable implementations, unless you can properly define what the Translate header means on each single HTTP/WebDAV method *and* get consensus on that and show that all Microsoft products are consistent with this. > > Actually, having a one-to-one mapping of executables to their > output (for > > instance foo.asp) is a very bad practice. Everytime you change your > > underlying implementation, URIs will change. However, cool URIs don't > > change. > > > > What URIs are you talking about? Can you give an example of > this? Clearly > there is widespread industry support for the one-to-one mapping > you describe > (cgi, .asp). That doesn't mean it's good practice. See [1] (by Tim BL himself). [1] From w3c-dist-auth-request@w3.org Thu Feb 28 14:05:04 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13277 for ; Thu, 28 Feb 2002 14:05:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA20883; Thu, 28 Feb 2002 14:03:38 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 14:03:38 -0500 (EST) Resent-Message-Id: <200202281903.OAA20883@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 OAA20862 for ; Thu, 28 Feb 2002 14:03:15 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA10691 for ; Thu, 28 Feb 2002 14:03:15 -0500 Received: (qmail 8072 invoked by uid 0); 28 Feb 2002 19:02:44 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp002-rz3) with SMTP; 28 Feb 2002 19:02:44 -0000 From: "Julian Reschke" To: Date: Thu, 28 Feb 2002 20:02:42 +0100 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 V6.00.2600.0000 Importance: Normal Subject: FW: href in where clause Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5977 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 (moving it to the right list) So maybe the RFC should say that "DAV:displayname" is a computed property based on the name of the collection member? Does anybody have a problem with this? Julian > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Thursday, February 28, 2002 7:57 PM > To: 'Julian Reschke'; 'dasl' > Subject: RE: href in where clause > > > In the server implementations I'm aware of: > - displayname is not writable, because making it writable would be > equivalent in these systems to a MOVE (rename) > - displayname must be unique within a collection > > Lisa > > > -----Original Message----- > > From: www-webdav-dasl-request@w3.org > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke > > Sent: Thursday, February 28, 2002 10:29 AM > > To: 'dasl' > > Subject: RE: href in where clause > > > > > > Correct. > > > > Is it writable? Do all members of a collection have different > > displaynames? > > > > Julian > > > > > -----Original Message----- > > > From: www-webdav-dasl-request@w3.org > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Lisa Dusseault > > > Sent: Thursday, February 28, 2002 6:36 PM > > > To: 'Julian Reschke'; 'dasl' > > > Subject: RE: href in where clause > > > > > > > > > A related problem, perhaps for RFC2518, is how displayname > > should be used. > > > If displayname is only the final path segment or filename of a > > > href (as most > > > products seem to be implemented), then displayname might be > > sufficient for > > > most of the kinds of searches you could do with href. > > > > > > Lisa > > > > > > > -----Original Message----- > > > > From: www-webdav-dasl-request@w3.org > > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke > > > > Sent: Thursday, February 28, 2002 6:20 AM > > > > To: dasl > > > > Subject: DAV:href in where clause > > > > > > > > > > > > DAV:href isn't a property, so it can't be used in queries. > > > > > > > > Is this a problem? Examples where DAV:displayname is queried > > > > instead seem to > > > > indicate that. A possible solution would be to allow DAV:href > > > > whereever > > > > DAV:prop is allowed in the where clause. > > > > > > > > For instance: > > > > > > > > > > > > > > > > > > > > %.doc > > > > > > > > > > > > > > > > Of course it would be a problem that WebDAV is silent about > > > > the allowed > > > > formats that can appear in the href element (authority > > > > mandatory? which > > > > forms of relative URI references are allowed and interoperable?). > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 28 14:26:01 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14490 for ; Thu, 28 Feb 2002 14:26:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA21834; Thu, 28 Feb 2002 14:24:54 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 14:24:54 -0500 (EST) Resent-Message-Id: <200202281924.OAA21834@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 OAA21809 for ; Thu, 28 Feb 2002 14:24:35 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA13009 for ; Thu, 28 Feb 2002 14:24:35 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Thu, 28 Feb 2002 14:22:38 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 14:24:02 -0500 Message-ID: <982A819715AC804D915E8A053B48CBB802AC9606@sus-ma1it04.rational.com> From: "Vasta, John" To: "'Julian Reschke'" , w3c-dist-auth@w3c.org Date: Thu, 28 Feb 2002 14:24:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: href in where clause Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5978 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 would object to such a change. In our system, many kinds of resources have both "object names" and "titles", the latter being a writable property of an object. We preferentially display titles as identifiers in user interfaces. I interpreted DAV:displayname as "the resource name a client is encouraged to show the user", so it would map pretty naturally to our our title property (and object names are used for URI's). They don't have to be unique, or have anything to do with the object name, and they can be changed any time. John > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, February 28, 2002 2:03 PM > To: w3c-dist-auth@w3c.org > Subject: FW: href in where clause > > > (moving it to the right list) > > So maybe the RFC should say that "DAV:displayname" is a > computed property > based on the name of the collection member? Does anybody have > a problem with > this? > > Julian > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Thursday, February 28, 2002 7:57 PM > > To: 'Julian Reschke'; 'dasl' > > Subject: RE: href in where clause > > > > > > In the server implementations I'm aware of: > > - displayname is not writable, because making it writable would be > > equivalent in these systems to a MOVE (rename) > > - displayname must be unique within a collection > > > > Lisa > > > > > -----Original Message----- > > > From: www-webdav-dasl-request@w3.org > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke > > > Sent: Thursday, February 28, 2002 10:29 AM > > > To: 'dasl' > > > Subject: RE: href in where clause > > > > > > > > > Correct. > > > > > > Is it writable? Do all members of a collection have different > > > displaynames? > > > > > > Julian > > > > > > > -----Original Message----- > > > > From: www-webdav-dasl-request@w3.org > > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of > Lisa Dusseault > > > > Sent: Thursday, February 28, 2002 6:36 PM > > > > To: 'Julian Reschke'; 'dasl' > > > > Subject: RE: href in where clause > > > > > > > > > > > > A related problem, perhaps for RFC2518, is how displayname > > > should be used. > > > > If displayname is only the final path segment or filename of a > > > > href (as most > > > > products seem to be implemented), then displayname might be > > > sufficient for > > > > most of the kinds of searches you could do with href. > > > > > > > > Lisa > > > > > > > > > -----Original Message----- > > > > > From: www-webdav-dasl-request@w3.org > > > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of > Julian Reschke > > > > > Sent: Thursday, February 28, 2002 6:20 AM > > > > > To: dasl > > > > > Subject: DAV:href in where clause > > > > > > > > > > > > > > > DAV:href isn't a property, so it can't be used in queries. > > > > > > > > > > Is this a problem? Examples where DAV:displayname is queried > > > > > instead seem to > > > > > indicate that. A possible solution would be to allow DAV:href > > > > > whereever > > > > > DAV:prop is allowed in the where clause. > > > > > > > > > > For instance: > > > > > > > > > > > > > > > > > > > > > > > > > %.doc > > > > > > > > > > > > > > > > > > > > Of course it would be a problem that WebDAV is silent about > > > > > the allowed > > > > > formats that can appear in the href element (authority > > > > > mandatory? which > > > > > forms of relative URI references are allowed and > interoperable?). > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 28 14:36:37 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15118 for ; Thu, 28 Feb 2002 14:36:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22247; Thu, 28 Feb 2002 14:35:06 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 14:35:06 -0500 (EST) Resent-Message-Id: <200202281935.OAA22247@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 OAA22221 for ; Thu, 28 Feb 2002 14:34:45 -0500 (EST) Received: from libaxp.sonoma.edu (libaxp.sonoma.edu [130.157.2.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA14310 for ; Thu, 28 Feb 2002 14:34:44 -0500 Received: from conversion.sonoma.edu by SONOMA.EDU (PMDF V5.2-32 #39389) id <01KET12DYJ4095Q7G3@SONOMA.EDU> for w3c-dist-auth@w3.org; Thu, 28 Feb 2002 11:34:26 PST Received: from [130.157.200.110] by SONOMA.EDU (PMDF V5.2-32 #39389) with ESMTP id <01KET12DM6KG95Q8U0@SONOMA.EDU> for w3c-dist-auth@w3.org; Thu, 28 Feb 2002 11:34:19 -0800 (PST) Date: Thu, 28 Feb 2002 11:32:53 -0800 From: CJ Holmes In-reply-to: X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) To: w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" ; format="flowed" References: Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5979 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: > > The only time Translate/GETSRC is relevant is for executables (cgi's, >> servlets, etc.) at a particular URL which generate some dynamic content. > >I don't agree. DAV:source may be relevant for "compiled" resources as well. >For instance, static HTML might be generated by a one-time compilation >process, but you don't want anybody to *modify* the HTML. Rather, people >would need to be pointed to the modifiable source (for instance, XML and >XSLT input files). Agreed. I am not arguing against DAV:source at all. I think it is a good idea, and I recognize its architectural superiority. What I object to is that the current model makes simple things very hard to implement and a hassle to manage for no real gain to most people. > > So, there are really three different sets of content we are looking at: >> >> 1) the generated output returned by GET >> >> 2) the executable that generates the content for GET, and which is the >> object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK, >> MOVE, COPY, > > ...) > > 3) the multiple source files that were used to generate the executable >> >> >> The GET method returns resource #1, dav:source (if it were actually >> implemented by anyone) would list #3. Translate: F, or GETSRC, returns >> resource #2, which is the one logically consistent with the other WebDAV >> methods. > >Yes, but dav:source can do this for you as well. Why have two different >models if one is enough? Nobody is suggesting two models. I'm suggesting a change in the current model. Instead of GETSRC, let's call it DAVGET just to relieve us of some preconceptions. GET is undefined by DAV PUT and DAVGET are symmetric Properties belong the result of DAVGET If URI "x" is compiled from sources at other URIs, then: DAVGET "x" will retrieve the resource PROPFIND "x" will retrieve the properties of DAVGET "x" GET "x" would probably return the same resource as DAVGET "x" (impl dependent) PUT "x" will result in an error (impl. dependent), since the sources lie elsewhere. PUT to the source URI(s) of "x" will affect the properties and value of DAVGET "x" You can still have DAV:source and it will be just as useful as it is now. But the common problem of how people use DAV to edit their source files is resolved. > > Real-world experience has shown that: >> >> * nobody actually tracks multiple source files for an executable >> * people sometimes want to actually get the executable contents >> >> Nobody has actually come up with a real-world use-case for dav:source, but >> whether or not dav:source is deprecated or not, it's actually >> identifying a >> different set of content than Translate: F / GETSRC. > >I disagree. Could you please explain why the model used in DAV:source can't >be applied to this use case? It can, but it just isn't worth the trouble. It is a LOT of extra work for absolutely no gain. You gain nothing from DAV:source that you don't get for 1/20th the work from Translate. If I were to spend a programmer month implementing DAV:source, administrators would still have to set aside special URL spaces and turn off all plug-ins for that space and add a lot of new security realms, just like they do now. We could implement it, but in terms of managing the server we're left with the same mess that already afflicts our users. There's just no point in implementing DAV:source unless you have some kind of tightly-integrated document management/compilation system that tracks multiple sources for the GET results of dynamic URI(s). And so we're left in a situations where the simplest task is quite difficult. >Actually, having a one-to-one mapping of executables to their output (for >instance foo.asp) is a very bad practice. Everytime you change your >underlying implementation, URIs will change. However, cool URIs don't >change. Nobody is trying to tie down executables to output on a one-to-one basis. Nobody is trying to get rid of DAV:source. We're just trying to adjust the current model to make the simple things easy, while maintaining support for the the difficult (and architecturally more interesting) things. cjh -- From w3c-dist-auth-request@w3.org Thu Feb 28 14:46:54 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15599 for ; Thu, 28 Feb 2002 14:46:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22804; Thu, 28 Feb 2002 14:44:45 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 14:44:45 -0500 (EST) Resent-Message-Id: <200202281944.OAA22804@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 OAA22770 for ; Thu, 28 Feb 2002 14:44:25 -0500 (EST) Received: from inet-mail2.oracle.com (inet-mail2.oracle.com [148.87.2.202]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA16134 for ; Thu, 28 Feb 2002 14:44:24 -0500 Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail2.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1SJiMI16534; Thu, 28 Feb 2002 11:44:22 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g1SJiGK20105; Thu, 28 Feb 2002 12:44:16 -0700 (MST) From: "Eric Sedlar" To: "Julian Reschke" , Date: Thu, 28 Feb 2002 11:44:10 -0800 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: href in where clause Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5980 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 thought the intent of dav:displayname was to be able to hold information like the element that could be parsed out of an HTML file. I think that the collection member name is more of a default value for displayname than something that is required to correspond to the appropriate piece of the URL. I don't think we should make such a change. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Thursday, February 28, 2002 11:03 AM > To: w3c-dist-auth@w3c.org > Subject: FW: href in where clause > > > (moving it to the right list) > > So maybe the RFC should say that "DAV:displayname" is a computed property > based on the name of the collection member? Does anybody have a > problem with > this? > > Julian > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Thursday, February 28, 2002 7:57 PM > > To: 'Julian Reschke'; 'dasl' > > Subject: RE: href in where clause > > > > > > In the server implementations I'm aware of: > > - displayname is not writable, because making it writable would be > > equivalent in these systems to a MOVE (rename) > > - displayname must be unique within a collection > > > > Lisa > > > > > -----Original Message----- > > > From: www-webdav-dasl-request@w3.org > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke > > > Sent: Thursday, February 28, 2002 10:29 AM > > > To: 'dasl' > > > Subject: RE: href in where clause > > > > > > > > > Correct. > > > > > > Is it writable? Do all members of a collection have different > > > displaynames? > > > > > > Julian > > > > > > > -----Original Message----- > > > > From: www-webdav-dasl-request@w3.org > > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Lisa Dusseault > > > > Sent: Thursday, February 28, 2002 6:36 PM > > > > To: 'Julian Reschke'; 'dasl' > > > > Subject: RE: href in where clause > > > > > > > > > > > > A related problem, perhaps for RFC2518, is how displayname > > > should be used. > > > > If displayname is only the final path segment or filename of a > > > > href (as most > > > > products seem to be implemented), then displayname might be > > > sufficient for > > > > most of the kinds of searches you could do with href. > > > > > > > > Lisa > > > > > > > > > -----Original Message----- > > > > > From: www-webdav-dasl-request@w3.org > > > > > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke > > > > > Sent: Thursday, February 28, 2002 6:20 AM > > > > > To: dasl > > > > > Subject: DAV:href in where clause > > > > > > > > > > > > > > > DAV:href isn't a property, so it can't be used in queries. > > > > > > > > > > Is this a problem? Examples where DAV:displayname is queried > > > > > instead seem to > > > > > indicate that. A possible solution would be to allow DAV:href > > > > > whereever > > > > > DAV:prop is allowed in the where clause. > > > > > > > > > > For instance: > > > > > > > > > > <D:where> > > > > > <D:like> > > > > > <D:href/> > > > > > <D:literal>%.doc</D:literal> > > > > > </D:like> > > > > > </D:where> > > > > > > > > > > Of course it would be a problem that WebDAV is silent about > > > > > the allowed > > > > > formats that can appear in the href element (authority > > > > > mandatory? which > > > > > forms of relative URI references are allowed and interoperable?). > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Feb 28 15:39:34 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18606 for <webdav-archive@odin.ietf.org>; Thu, 28 Feb 2002 15:39:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26549; Thu, 28 Feb 2002 15:38:41 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 15:38:41 -0500 (EST) Resent-Message-Id: <200202282038.PAA26549@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 PAA26528 for <w3c-dist-auth@www19.w3.org>; Thu, 28 Feb 2002 15:38:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA24497 for <w3c-dist-auth@w3.org>; Thu, 28 Feb 2002 15:38:19 -0500 Received: (qmail 18816 invoked by uid 0); 28 Feb 2002 20:37:48 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp007-rz3) with SMTP; 28 Feb 2002 20:37:48 -0000 From: "Julian Reschke" <julian.reschke@gmx.de> To: "CJ Holmes" <cholmes@4d.com>, <w3c-dist-auth@w3.org> Date: Thu, 28 Feb 2002 21:37:46 +0100 Message-ID: <JIEGINCHMLABHJBIGKBCAEAFECAA.julian.reschke@gmx.de> 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 V6.00.2600.0000 Importance: Normal In-Reply-To: <a05101400b8a42eaffce8@[130.157.200.110]> Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/5981 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: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > Sent: Thursday, February 28, 2002 8:33 PM > To: w3c-dist-auth@w3.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > > > The only time Translate/GETSRC is relevant is for executables (cgi's, > >> servlets, etc.) at a particular URL which generate some > dynamic content. > > > >I don't agree. DAV:source may be relevant for "compiled" > resources as well. > >For instance, static HTML might be generated by a one-time compilation > >process, but you don't want anybody to *modify* the HTML. Rather, people > >would need to be pointed to the modifiable source (for instance, XML and > >XSLT input files). > > > Agreed. I am not arguing against DAV:source at all. I think it is a > good idea, and I recognize its architectural superiority. > > What I object to is that the current model makes simple things very > hard to implement and a hassle to manage for no real gain to most > people. I think you need to prove that if you want to introduce a second model for something that could be solved using DAV:source. > > > So, there are really three different sets of content we are > looking at: > >> > >> 1) the generated output returned by GET > >> > >> 2) the executable that generates the content for GET, and > which is the > >> object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK, > >> MOVE, COPY, > > > ...) > > > 3) the multiple source files that were used to generate > the executable > >> > >> > >> The GET method returns resource #1, dav:source (if it were actually > >> implemented by anyone) would list #3. Translate: F, or > GETSRC, returns > >> resource #2, which is the one logically consistent with the > other WebDAV > >> methods. > > > >Yes, but dav:source can do this for you as well. Why have two different > >models if one is enough? > > Nobody is suggesting two models. I'm suggesting a change in the > current model. Instead of GETSRC, let's call it DAVGET just to > relieve us of some preconceptions. > > GET is undefined by DAV > PUT and DAVGET are symmetric > Properties belong the result of DAVGET > If URI "x" is compiled from sources at other URIs, then: > DAVGET "x" will retrieve the resource > PROPFIND "x" will retrieve the properties of DAVGET "x" > GET "x" would probably return the same resource as > DAVGET "x" (impl dependent) > PUT "x" will result in an error (impl. dependent), > since the sources lie elsewhere. > PUT to the source URI(s) of "x" will affect the > properties and value of DAVGET "x" Having a new GET method that returns completely different resources than GET, and defining that PROPFIND operates on DAVGET rather than GET is not only a new model, it would change WebDAV at it's core. Why do this if this isn't needed???? > You can still have DAV:source and it will be just as useful as it is > now. But the common problem of how people use DAV to edit their > source files is resolved. It can *easily* be solved using DAV:source. > > > Real-world experience has shown that: > >> > >> * nobody actually tracks multiple source files for an executable > >> * people sometimes want to actually get the executable contents > >> > >> Nobody has actually come up with a real-world use-case for > dav:source, but > >> whether or not dav:source is deprecated or not, it's actually > >> identifying a > >> different set of content than Translate: F / GETSRC. > > > >I disagree. Could you please explain why the model used in > DAV:source can't > >be applied to this use case? > > It can, but it just isn't worth the trouble. It is a LOT of extra > work for absolutely no gain. You gain nothing from DAV:source that > you don't get for 1/20th the work from Translate. That's a broad claim. Can you prove it? > If I were to spend a programmer month implementing DAV:source, Why would that take so long? > administrators would still have to set aside special URL spaces and > turn off all plug-ins for that space and add a lot of new security No, they don't. Nobody says that they *have* to set aside a special URL space. For instance, for any "output" resource "x", you could have a source resource "x" + ".~~~~~source~~~~~" which represents the editable source code of this resource. No separate URL space. > realms, just like they do now. We could implement it, but in terms > of managing the server we're left with the same mess that already > afflicts our users. There's just no point in implementing DAV:source > unless you have some kind of tightly-integrated document > management/compilation system that tracks multiple sources for the > GET results of dynamic URI(s). The only difference is that you might have more than one source. It escapes me why the special case of having just one source justifies breaking basic Web axioms by having different resources with the same URI. > And so we're left in a situations where the simplest task is > quite difficult. No, it's not. Maybe you could step back and describe why you think it's so much more work generating a second URI for the editable source resource. > >Actually, having a one-to-one mapping of executables to their output (for > >instance foo.asp) is a very bad practice. Everytime you change your > >underlying implementation, URIs will change. However, cool URIs don't > >change. > > Nobody is trying to tie down executables to output on a one-to-one > basis. Nobody is trying to get rid of DAV:source. We're just trying > to adjust the current model to make the simple things easy, while > maintaining support for the the difficult (and architecturally more > interesting) things. From w3c-dist-auth-request@w3.org Thu Feb 28 17:16:46 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22807 for <webdav-archive@odin.ietf.org>; Thu, 28 Feb 2002 17:16:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA00959; Thu, 28 Feb 2002 17:11:02 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 17:11:02 -0500 (EST) Resent-Message-Id: <200202282211.RAA00959@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 RAA00915 for <w3c-dist-auth@www19.w3.org>; Thu, 28 Feb 2002 17:10:43 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA03851 for <w3c-dist-auth@w3.org>; Thu, 28 Feb 2002 17:10:44 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Thu, 28 Feb 2002 17:08:48 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <FJQFMMBS>; Thu, 28 Feb 2002 17:10:13 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AFDC@SUS-MA1IT01> From: "Clemm, Geoff" <gclemm@rational.com> To: w3c-dist-auth@w3.org Date: Thu, 28 Feb 2002 17:10:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/5982 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: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> I agree with Julian's question, i.e. why don't you just use some natural URL to expose your editable source. In general, the file extension of the actual file containing your editable source will not be ".html". It will be .asp, .jsp, or whatever. So the natural URL for the jsp source for /x/y/foo.html is /x/y/foo.jsp. Why not just use that URI to identify your source resource? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, February 28, 2002 3:38 PM To: CJ Holmes; w3c-dist-auth@w3.org Subject: RE: A case for GETSRC (or other mechanism to that effect) > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > Sent: Thursday, February 28, 2002 8:33 PM > To: w3c-dist-auth@w3.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > > > The only time Translate/GETSRC is relevant is for executables (cgi's, > >> servlets, etc.) at a particular URL which generate some > dynamic content. > > > >I don't agree. DAV:source may be relevant for "compiled" > resources as well. > >For instance, static HTML might be generated by a one-time compilation > >process, but you don't want anybody to *modify* the HTML. Rather, people > >would need to be pointed to the modifiable source (for instance, XML and > >XSLT input files). > > > Agreed. I am not arguing against DAV:source at all. I think it is a > good idea, and I recognize its architectural superiority. > > What I object to is that the current model makes simple things very > hard to implement and a hassle to manage for no real gain to most > people. I think you need to prove that if you want to introduce a second model for something that could be solved using DAV:source. > > > So, there are really three different sets of content we are > looking at: > >> > >> 1) the generated output returned by GET > >> > >> 2) the executable that generates the content for GET, and > which is the > >> object of all other methods (PROPFIND, PROPPATCH, LOCK, UNLOCK, > >> MOVE, COPY, > > > ...) > > > 3) the multiple source files that were used to generate > the executable > >> > >> > >> The GET method returns resource #1, dav:source (if it were actually > >> implemented by anyone) would list #3. Translate: F, or > GETSRC, returns > >> resource #2, which is the one logically consistent with the > other WebDAV > >> methods. > > > >Yes, but dav:source can do this for you as well. Why have two different > >models if one is enough? > > Nobody is suggesting two models. I'm suggesting a change in the > current model. Instead of GETSRC, let's call it DAVGET just to > relieve us of some preconceptions. > > GET is undefined by DAV > PUT and DAVGET are symmetric > Properties belong the result of DAVGET > If URI "x" is compiled from sources at other URIs, then: > DAVGET "x" will retrieve the resource > PROPFIND "x" will retrieve the properties of DAVGET "x" > GET "x" would probably return the same resource as > DAVGET "x" (impl dependent) > PUT "x" will result in an error (impl. dependent), > since the sources lie elsewhere. > PUT to the source URI(s) of "x" will affect the > properties and value of DAVGET "x" Having a new GET method that returns completely different resources than GET, and defining that PROPFIND operates on DAVGET rather than GET is not only a new model, it would change WebDAV at it's core. Why do this if this isn't needed???? > You can still have DAV:source and it will be just as useful as it is > now. But the common problem of how people use DAV to edit their > source files is resolved. It can *easily* be solved using DAV:source. > > > Real-world experience has shown that: > >> > >> * nobody actually tracks multiple source files for an executable > >> * people sometimes want to actually get the executable contents > >> > >> Nobody has actually come up with a real-world use-case for > dav:source, but > >> whether or not dav:source is deprecated or not, it's actually > >> identifying a > >> different set of content than Translate: F / GETSRC. > > > >I disagree. Could you please explain why the model used in > DAV:source can't > >be applied to this use case? > > It can, but it just isn't worth the trouble. It is a LOT of extra > work for absolutely no gain. You gain nothing from DAV:source that > you don't get for 1/20th the work from Translate. That's a broad claim. Can you prove it? > If I were to spend a programmer month implementing DAV:source, Why would that take so long? > administrators would still have to set aside special URL spaces and > turn off all plug-ins for that space and add a lot of new security No, they don't. Nobody says that they *have* to set aside a special URL space. For instance, for any "output" resource "x", you could have a source resource "x" + ".~~~~~source~~~~~" which represents the editable source code of this resource. No separate URL space. > realms, just like they do now. We could implement it, but in terms > of managing the server we're left with the same mess that already > afflicts our users. There's just no point in implementing DAV:source > unless you have some kind of tightly-integrated document > management/compilation system that tracks multiple sources for the > GET results of dynamic URI(s). The only difference is that you might have more than one source. It escapes me why the special case of having just one source justifies breaking basic Web axioms by having different resources with the same URI. > And so we're left in a situations where the simplest task is > quite difficult. No, it's not. Maybe you could step back and describe why you think it's so much more work generating a second URI for the editable source resource. > >Actually, having a one-to-one mapping of executables to their output (for > >instance foo.asp) is a very bad practice. Everytime you change your > >underlying implementation, URIs will change. However, cool URIs don't > >change. > > Nobody is trying to tie down executables to output on a one-to-one > basis. Nobody is trying to get rid of DAV:source. We're just trying > to adjust the current model to make the simple things easy, while > maintaining support for the the difficult (and architecturally more > interesting) things. From w3c-dist-auth-request@w3.org Thu Feb 28 19:10:20 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27219 for <webdav-archive@odin.ietf.org>; Thu, 28 Feb 2002 19:10:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA08275; Thu, 28 Feb 2002 19:09:13 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 19:09:13 -0500 (EST) Resent-Message-Id: <200203010009.TAA08275@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 TAA08253 for <w3c-dist-auth@www19.w3.org>; Thu, 28 Feb 2002 19:09:03 -0500 (EST) Received: from melvax.sonoma.edu (melvax.sonoma.edu [130.157.2.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA22194 for <w3c-dist-auth@w3c.org>; Thu, 28 Feb 2002 19:09:03 -0500 Received: from conversion.sonoma.edu by SONOMA.EDU (PMDF V5.2-32 #39389) id <01KETAMOIQY893DFN8@SONOMA.EDU> for w3c-dist-auth@w3c.org; Thu, 28 Feb 2002 16:08:28 PST Received: from [130.157.200.114] by SONOMA.EDU (PMDF V5.2-32 #39389) with ESMTP id <01KETALQ7QDQ95QEES@SONOMA.EDU>; Thu, 28 Feb 2002 16:07:13 -0800 (PST) Date: Thu, 28 Feb 2002 16:05:42 -0800 From: CJ Holmes <cholmes@4d.com> In-reply-to: <3906C56A7BD1F54593344C05BD1374B103F8AFDE@SUS-MA1IT01> X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) To: "Clemm, Geoff" <gclemm@rational.com> Cc: w3c-dist-auth@w3c.org Message-id: <a05101400b8a471a93a26@[130.157.200.114]> MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" ; format="flowed" References: <3906C56A7BD1F54593344C05BD1374B103F8AFDE@SUS-MA1IT01> Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/5983 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: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> >Why is it easier to get the server to implement GETSRC >(which requires it both to locate, and then retrieve the >contents of the source) than it is to get the server >to implement PROPFIND <DAV:source>, where it just has to >locate the source, and return its URL? Well, you can't always "just locate the source". If the source really is in a different location than the "normal" URI then your DAV module probably has no knowledge of it. Which means now you have to teach JSP to be DAV-aware and answer PROPFIND requests, or teach your DAV module all about what URIs are served by which other modules and how the two URI spaces map to each other. In the more common case where "GET x" is dynamically generated from some source at the same URI, then there's hardly anything to be done at all to support GETSRC. All of the same machinery that normally locates a file works just like it did before, which is the beauty of it. The only differences are: 1. The security module checks to make sure that the user has permission to "GETSRC x". In Apache, this is just a matter of adding GETSRC to the list of methods a user is allowed to use within a given realm. 2. The PHP/JSP/Whatever plug-in doesn't try to pick up the request, because it doesn't know what to do with a GETSRC method. (Just like it doesn't try to claim anything with PROPFIND or DELETE methods.) In fact, all plug-ins that work only with GET, HEAD, and POST methods just ignore the request entirely, which is what you want for serving "source" data. 3. Either the DAV module can claim the request, or the mechanism that serves static files can serve the request. In our case (WebSTAR) we would probably just let the "default" plug-in do it, since that module normally serves static content without interpretation and it supports byte ranges, which is handy. There's no point in duplicating that code in the DAV plug-in. >-----Original Message----- >From: CJ Holmes [mailto:cholmes@4d.com] >Sent: Thursday, February 28, 2002 6:17 PM >To: Clemm, Geoff >Subject: RE: A case for GETSRC (or other mechanism to that effect) > > >>I agree with Julian's question, i.e. why don't you just use >>some natural URL to expose your editable source. In general, the >>file extension of the actual file containing your editable source >>will not be ".html". It will be .asp, .jsp, or whatever. So the >>natural URL for the jsp source for /x/y/foo.html is /x/y/foo.jsp. >>Why not just use that URI to identify your source resource? > >Most people don't configure their servers that way. If you want the >output of /x/y/foo.php then you "GET /x/y/foo.php". Short of a >different method or something like the "Translate" field there's no >natural way to tell the difference (both semantic and security) >between a "get the source" and "get the output". > >And even in cases where where servers are configured this way, you >have problems in trying to implement DAV:source or anything like it >properly. > >What happens when "FINDPROP /x/y/foo.html" is requested? If the DAV >module is responsible for handling it, then it has to understand >enough about the server's and other plug-ins' configuration to figure >out who creates that URI and what the appropriate source is. Which >means your DAV plug-in has to be rather tightly integrated with all >of your other plug-ins. > >On the other hand you could just let PHP handle PROPFIND for the URIs >it generates. But for that implementation model to be consistent you >need to DAV-enable every dynamic content creation tool and every CGI. >I don't think everyone is up to that. > >Again, DAV:source makes perfect sense for tightly integrated content >management systems, but not for the common case of web servers that >want to add DAV access to their source content. > >cjh > >-- -- From w3c-dist-auth-request@w3.org Thu Feb 28 19:51:01 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27830 for <webdav-archive@odin.ietf.org>; Thu, 28 Feb 2002 19:51:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA10872; Thu, 28 Feb 2002 19:49:59 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 19:49:59 -0500 (EST) Resent-Message-Id: <200203010049.TAA10872@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 TAA10847 for <w3c-dist-auth@www19.w3.org>; Thu, 28 Feb 2002 19:49:50 -0500 (EST) Received: from LIILMTLSSM01.mailtask.com (liilmtlssm01.mailtask.com [208.203.59.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA27321 for <w3c-dist-auth@w3.org>; Thu, 28 Feb 2002 19:49:50 -0500 Received: from moose ([216.36.111.249]) by LIILMTLSSM01.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 18:49:19 -0600 From: "Lisa Dusseault" <lisa@xythos.com> To: "'WebDAV'" <w3c-dist-auth@w3.org>, <frank.biederich@adobe.com> Date: Thu, 28 Feb 2002 16:50:32 -0800 Message-ID: <001101c1c0bb$19a25190$7801a8c0@moose> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <AMEPKEBLDJJCCDEJHAMICEKKEDAA.ejw@cse.ucsc.edu> X-OriginalArrivalTime: 01 Mar 2002 00:49:19.0125 (UTC) FILETIME=[EB8A6450:01C1C0BA] Subject: RE: Shared locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/5984 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: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> Content-Transfer-Encoding: 7bit Frank, have you tested interoperability of shared locks with the Xythos Sharemation server? What servers have you been able to create shared locks on? We'd only need one more interoperable client to be able to keep shared locks as we go forward. Lisa > -----Original Message----- > From: Frank Biederich [mailto:frank.biederich@adobe.com] > Sent: Thursday, February 21, 2002 7:14 AM > To: w3c-dist-auth@w3c.org > Subject: [Moderator Action] RE: Shared locks > > > Julian - > > > I don't think so. > > > > Our server passes the tests in the Litmus test (as does > moddav, I think), > > but I'm not aware of any client actually requesting shared locks... > > FYI, Adobe GoLive (version 5 or later) is able to do it. No > workflow is > built upon this feature, but you're able to set shared locks > on resources > using the included WebDAV browser. > > Best, Frank > > -- > Frank Biederich > Adobe Systems > frank.biederich@adobe.com > > http://www.adobe.com > http://www.adobe.com/golive > > From w3c-dist-auth-request@w3.org Thu Feb 28 23:40:25 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03919 for <webdav-archive@odin.ietf.org>; Thu, 28 Feb 2002 23:40:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA26893; Thu, 28 Feb 2002 23:39:34 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 23:39:34 -0500 (EST) Resent-Message-Id: <200203010439.XAA26893@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 XAA26760 for <w3c-dist-auth@www19.w3.org>; Thu, 28 Feb 2002 23:39:14 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA18769 for <w3c-dist-auth@w3c.org>; Thu, 28 Feb 2002 23:39:13 -0500 Received: from sus-ma1it00.rational.com ([192.168.215.70]) by sus-ma1it31.rational.com with Trend Micro InterScan Messaging Security Suite for SMTP v5.01; Thu, 28 Feb 2002 23:37:17 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id <FJQFMZKZ>; Thu, 28 Feb 2002 23:38:42 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105F84B0E@SUS-MA1IT01> From: "Clemm, Geoff" <gclemm@rational.com> To: w3c-dist-auth@w3c.org Date: Thu, 28 Feb 2002 23:38:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/5985 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: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> From: CJ Holmes [mailto:cholmes@4d.com] >Why is it easier to get the server to implement GETSRC >(which requires it both to locate, and then retrieve the >contents of the source) than it is to get the server >to implement PROPFIND <DAV:source>, where it just has to >locate the source, and return its URL? Well, you can't always "just locate the source". If the source really is in a different location than the "normal" URI then your DAV module probably has no knowledge of it. Which means now you have to teach JSP to be DAV-aware and answer PROPFIND requests, or teach your DAV module all about what URIs are served by which other modules and how the two URI spaces map to each other. I agree that in some implementations, it will take more work to teach the DAV module about how to map a display URI space to an authoring URI space. My primary objection to GETSRC is that it represents a non-extensible direction to follow. For example, one of the key purposes of PROPFIND was to provide semantic indexing of web resources, and the indexing of the display information should be significantly different from the indexing of the source information. Once you have taught the DAV module to understand the difference between display URL spaces and source URL spaces, it can produce this kind of indexing. Similarly, any other kind of method that could sensibly be applied to both the display and authoring resources can take advantage of the separation of display and authoring into separate identifiable URLs. So although possibly more work in the short run, I believe the work put into supporting a separate URL space is the direction that the protocol should be encouraging server vendors to pursue. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Feb 28 23:45:01 2002 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03965 for <webdav-archive@odin.ietf.org>; Thu, 28 Feb 2002 23:45:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA27198; Thu, 28 Feb 2002 23:44:17 -0500 (EST) Resent-Date: Thu, 28 Feb 2002 23:44:17 -0500 (EST) Resent-Message-Id: <200203010444.XAA27198@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 XAA27177 for <w3c-dist-auth@www19.w3.org>; Thu, 28 Feb 2002 23:43:56 -0500 (EST) Received: from gilliam.users.flyingcroc.net (gilliam.users.flyingcroc.net [207.246.128.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA19152 for <w3c-dist-auth@w3c.org>; Thu, 28 Feb 2002 23:43:56 -0500 Received: from unx51.staff.flyingcroc.net (unx51.staff.flyingcroc.net [207.246.150.51]) by gilliam.users.flyingcroc.net (8.9.3/8.9.3) with ESMTP id UAA24368 for <w3c-dist-auth@w3c.org>; Thu, 28 Feb 2002 20:43:45 -0800 (PST) Received: (from erk@localhost) by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g214fMP10340; Thu, 28 Feb 2002 20:41:22 -0800 (PST) (envelope-from erk) To: w3c-dist-auth@w3c.org References: <3906C56A7BD1F54593344C05BD1374B103F8AFDE@SUS-MA1IT01> <a05101400b8a471a93a26@[130.157.200.114]> Organization: Accretive Technology Group From: Erik Seaberg <erk@flyingcroc.com> Date: 28 Feb 2002 20:41:22 -0800 In-Reply-To: CJ Holmes's message of "Thu, 28 Feb 2002 16:05:42 -0800" Message-ID: <86heo0vr0t.fsf_-_@unx51.staff.flyingcroc.net> Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Source header instead of property? (was Re: A case for GETSRC (or other mechanism to that effect)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/5986 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: <w3c-dist-auth.w3.org> List-Help: <http://www.w3.org/Mail/> List-Unsubscribe: <mailto:w3c-dist-auth-request@w3.org?subject=unsubscribe> The only reason for GETSRC or "Translate: F" is to overload one URI for both the source and output resources, but it seems to me that breaks a lot of features. We suddenly need to duplicate most properties ({DAV:}getsrcetag, {DAV:}getsrccontenttype...) to deal well with caching and editing. You're likely to go through content negotiation and wind up editing just one variant without even realizing it (or worse, store one variant at the vanilla URI's corresponding filename and inhibit negotiation!). And Web development being the way it is, it's almost certain that when GETSRC seems to usually work on simplistic servers, hardly any clients will know how to use {DAV:}source in the cases where it won't. But if the output resource does have a separate URI, a PUT or LOCK or PROPPATCH on it probably doesn't make sense, so it's not likely that many modules will bother being compliant enough to answer a PROPFIND request for {DAV:}source (in my case, GET clients and DAV clients are talking to different servers entirely). An HTTP header containing the source URIs for an output resource (only for authenticated requests?) should be much easier to implement; would that be more likely to be widely adopted and used?