From w3c-dist-auth-request@w3.org Fri Mar 1 04:27: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 EAA02061 for ; Fri, 1 Mar 2002 04:27:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA13492; Fri, 1 Mar 2002 04:26:28 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 04:26:28 -0500 (EST) Resent-Message-Id: <200203010926.EAA13492@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 EAA13440 for ; Fri, 1 Mar 2002 04:26: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 EAA02574 for ; Fri, 1 Mar 2002 04:26:07 -0500 Received: (qmail 16772 invoked by uid 0); 1 Mar 2002 09:25:33 -0000 Received: from pd9e519c7.dip.t-dialin.net (HELO lisa) (217.229.25.199) by mail.gmx.net (mp002-rz3) with SMTP; 1 Mar 2002 09:25:33 -0000 From: "Julian Reschke" To: Date: Fri, 1 Mar 2002 10:25:27 +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 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/5987 X-Loop: w3c-dist-auth@w3.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: Friday, March 01, 2002 1:06 AM > To: Clemm, Geoff > Cc: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > >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 , 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 If it doesn't (which is completely OK), then DAV:source will be empty, GETSRC will fail (?) and GET/Translate:f will something unspecified, right? > 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 think you can't have both. Either do DAV-enable your output-resources, or don't. If you do, this is a WebDAV problem, and WebDAV has a solution for it (DAV:source). If you don't, it's outside the scope for WebDAV. IMHO it makes perfect sense to only DAV-enable the source resources. Why would you want to Author or Version output resources? > 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 Is it really at the same *URI*? Or does it only happen to be stored in this place in the local storage of the fileserver? If it is, it would be the same resource (as per definition of URI). Is it? I think this is a key question. > 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. From w3c-dist-auth-request@w3.org Fri Mar 1 06:09: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 GAA08867 for ; Fri, 1 Mar 2002 06:09:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA23406; Fri, 1 Mar 2002 06:08:33 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 06:08:33 -0500 (EST) Resent-Message-Id: <200203011108.GAA23406@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 GAA23363 for ; Fri, 1 Mar 2002 06:08: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 GAA17523 for ; Fri, 1 Mar 2002 06:08:13 -0500 Received: (qmail 32422 invoked by uid 0); 1 Mar 2002 11:07:51 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp006-rz3) with SMTP; 1 Mar 2002 11:07:51 -0000 From: "Julian Reschke" To: , Date: Fri, 1 Mar 2002 12:07:50 +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: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5988 X-Loop: w3c-dist-auth@w3.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. The WebDAV SEARCH draft currently has an issue regarding treatment of xml:space [1]: it says, that the basicsearch grammer should respect xml:space="default" in a literal element, so that xyz would really be equivalent to: xyz That's compatible with XML, but it's not consistent with WebDAV (which doesn't say anything about xml:space). The only benefit of xml:space for WebDAV I'm aware of is that you could have indented "beautified" message bodies and have the receiver care about whitespace removal. However, as both WebDAV request and response bodies are generated/consumed by code (not human readers), that's hardly important. So my proposal would be: 1) In WebDAV, state that whitespace *is* significant, 2) Drop the feature in WebDAV SEARCH's DAV:literal. Comments? [1] From w3c-dist-auth-request@w3.org Fri Mar 1 08:35: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 IAA23687 for ; Fri, 1 Mar 2002 08:35:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA05109; Fri, 1 Mar 2002 08:33:08 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 08:33:08 -0500 (EST) Resent-Message-Id: <200203011333.IAA05109@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 IAA05064 for ; Fri, 1 Mar 2002 08:32:53 -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 IAA07007 for ; Fri, 1 Mar 2002 08:32:52 -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, 01 Mar 2002 08:30:55 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 08:32:21 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105F84B44@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 1 Mar 2002 08:32:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5989 X-Loop: w3c-dist-auth@w3.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 special header would effectively break the ability for Web Search engines (e.g. google.com) to index the resource space, unless they were upgraded to re-crawl the URL space with the "Translate" header, and then store in their cache that the "Translate" header needs to be included in the request. Analogously, it becomes impossible to just embed a URL in a mail message that refers someone to the source ... you'd have to somehow include an annotation that says "and use the Translate header when you request this URL". These kinds of reasons make me strongly object to either the GETSRC method or a Translate header. Cheers, Geoff -----Original Message----- From: Erik Seaberg [mailto:erk@flyingcroc.com] Sent: Thursday, February 28, 2002 11:41 PM To: w3c-dist-auth@w3c.org Subject: Source header instead of property? (was Re: A case for GETSRC (or other mechanism to that effect)) 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? From w3c-dist-auth-request@w3.org Fri Mar 1 08:42: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 IAA24050 for ; Fri, 1 Mar 2002 08:42:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA05738; Fri, 1 Mar 2002 08:41:48 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 08:41:48 -0500 (EST) Resent-Message-Id: <200203011341.IAA05738@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 IAA05718 for ; Fri, 1 Mar 2002 08:41: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 IAA09871 for ; Fri, 1 Mar 2002 08:41:35 -0500 Received: (qmail 23201 invoked by uid 0); 1 Mar 2002 13:41:04 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 1 Mar 2002 13:41:04 -0000 From: "Julian Reschke" To: Date: Fri, 1 Mar 2002 14:41:04 +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: <3906C56A7BD1F54593344C05BD1374B105F84B44@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5990 X-Loop: w3c-dist-auth@w3.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 Thanks, Geoff. Sorry if I keep repeating myself, but: are the source and the output resource a) different resources, or b) variants of the same resource [1]. I say "a)", and thus they need to have different URIs. Julian [1] RFC2616, section 1.3 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 01, 2002 2:32 PM > To: w3c-dist-auth@w3c.org > Subject: RE: Source header instead of property? (was Re: A case for > GETSR C (or other mechanism to that effect)) > > > The special header would effectively break the ability for Web Search > engines (e.g. google.com) to index the resource space, unless they were > upgraded to re-crawl the URL space with the "Translate" header, and > then store in their cache that the "Translate" header needs to be > included in the request. Analogously, it becomes impossible to just > embed a URL in a mail message that refers someone to the source ... > you'd have to somehow include an annotation that says "and use the > Translate header when you request this URL". These kinds of reasons > make me strongly object to either the GETSRC method or a Translate > header. > > Cheers, > Geoff > > -----Original Message----- > From: Erik Seaberg [mailto:erk@flyingcroc.com] > Sent: Thursday, February 28, 2002 11:41 PM > To: w3c-dist-auth@w3c.org > Subject: Source header instead of property? (was Re: A case for GETSRC > (or other mechanism to that effect)) > > > 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? > From w3c-dist-auth-request@w3.org Fri Mar 1 09:21: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 JAA26381 for ; Fri, 1 Mar 2002 09:21:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA10009; Fri, 1 Mar 2002 09:20:10 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 09:20:10 -0500 (EST) Resent-Message-Id: <200203011420.JAA10009@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 JAA09968 for ; Fri, 1 Mar 2002 09:19:47 -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 JAA20122 for ; Fri, 1 Mar 2002 09:19:40 -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, 01 Mar 2002 15:19:11 +0100 Date: Fri, 1 Mar 2002 15:19:11 +0100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: w3c-dist-auth@w3c.org To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105F84B44@SUS-MA1IT01> Message-Id: <4D12C9DC-2D1F-11D6-8C26-00039384827E@greenbytes.de> 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@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id JAA09968 Subject: Re: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5991 X-Loop: w3c-dist-auth@w3.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 Not speaking of the problem how the heck google is to display search results for such source documents... But by then we probably have extended HTML to handle link to interesting source in all browsers. Piece of cake really. //Stefan Am Freitag den, 1. März 2002, um 14:32, schrieb Clemm, Geoff: > The special header would effectively break the ability for Web Search > engines (e.g. google.com) to index the resource space, unless they were > upgraded to re-crawl the URL space with the "Translate" header, and > then store in their cache that the "Translate" header needs to be > included in the request. Analogously, it becomes impossible to just > embed a URL in a mail message that refers someone to the source ... > you'd have to somehow include an annotation that says "and use the > Translate header when you request this URL". These kinds of reasons > make me strongly object to either the GETSRC method or a Translate > header. > > Cheers, > Geoff > > -----Original Message----- > From: Erik Seaberg [mailto:erk@flyingcroc.com] > Sent: Thursday, February 28, 2002 11:41 PM > To: w3c-dist-auth@w3c.org > Subject: Source header instead of property? (was Re: A case for GETSRC > (or other mechanism to that effect)) > > > 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? > > From w3c-dist-auth-request@w3.org Fri Mar 1 11:11: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 LAA02699 for ; Fri, 1 Mar 2002 11:11:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA23853; Fri, 1 Mar 2002 11:04:50 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 11:04:50 -0500 (EST) Resent-Message-Id: <200203011604.LAA23853@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 LAA23815 for ; Fri, 1 Mar 2002 11:04:38 -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 LAA13916 for ; Fri, 1 Mar 2002 11:04:38 -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 LAA350956; Fri, 1 Mar 2002 11:00:52 -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 g21G44r50000; Fri, 1 Mar 2002 11:04:05 -0500 To: CJ Holmes Cc: "Clemm, Geoff" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 1 Mar 2002 10:57:29 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 03/01/2002 11:04:04 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/5992 X-Loop: w3c-dist-auth@w3.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 didn't understand Julian's response clearly, so I'll take another stab at a response. Firstly I assume the reason that you are discussing difficulty is that you're trying to prove that GETSRC is easier to implement/use than DAV:source. I do agree that GETSRC is probably at least a little easier, but if we're talking about a system where one output resource maps to one source resource, they both are almost the same. (If not, that needs to be proven.) To compare GETSRC handing a 1::1 mapping to DAV:source handing a many:many or many::many mapping of source to output isn't a fair comparison of GETSRC vs DAV:source. That's more a comparison of the complexity of supporting 1::1 vs many::1 mappings. If it's really DAV:source vs GETSRC that you want to compare, you only should be looking at 1::1 mappings. OTOH... if you're not really talking about GETSRC vs DAV:source, but really just talking about the complexity of supporting a 1::1 mapping if you are also supporting a many::many or many::1 mapping, then I think that comparison is more appropriate, but I also think that we haven't clearly defined a protocol that supports many::many yet. As we've pointed out, DAV:source really isn't clearly defined. We don't know what kind of flexibility it will be defined to support so we don't know what kind of burden it creates. Until it's defined, we can't really envision what it's like to support a many::many mapping. I hope we rapidly define how DAV:source supports composition from many underlying resources. Then we do the comparison. Anyway... what I say below assumes you're talking about comparing GETSRC vs DAV:source on a server that just supports 1::1 mappings. If this is not your scenario, please forgive me. > >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 , 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. But in your case of GETSRC you have to do the same thing. If it's hard for one, it's hard for the other. Just because a server supports DAV:source doesn't mean that it's going to put it's data in weird hard-to-find places. It's very likely to put everything physically in the same place a pure GETSRC server would. << 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. >> Having the JSP be DAV-aware is of course a terrible burden, but I don't think anyone is suggesting it needs to be. The mapping would not be done at the JSP layer. And even if it would be, it would be the same mapping that one would use for a pure GETSRC server. << 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. >> That sounds great. But the same would almost certainly be true for a server that supports DAV:source. It doesn't have to be true for such a server, but it doesn't have to be true for a pure GETSRC server either. But it seems reasonable to keep the underlying resource where you've described so both implementations are likely to do it that way. << 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. >> I think these three points are more to the point. This sounds pretty easy and that was half your point. The other half of your point is that it's hard to support DAV:source. I think a supporter of DAV:source would say that they'd just install a filter in Apache for URL's with a magical something in them that distinguishes them and would handle all method calls to those resources. If you want to prove that doing DAV:source is much harder than doing GETSRC, someone still needs to show that doing DAV:source is hard. My intuition tells me it isn't as easy as GETSRC, but that it probably couldn't be described as hard. Again, this is all only for a server that is only supporting 1::1 mappings. Any other type of server isn't clearly defined yet. FWIW... I don't think anyone so far has proposed that a server support GETSRC without supporting DAV:source, so pointing out that GETSRC is easier for a server to implement than DAV:source is a moot point because in the current proposals the servers would implement DAV:source anyway and implementing GETSRC would be an optional extra effort (only?) to offer clients a way to access the source of a resource in single HTTP request rather than having to do a PROPFIND first. Anyway, see my comments at the top of this posting. They might make much of this moot. J. From w3c-dist-auth-request@w3.org Fri Mar 1 11:44:12 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 LAA05093 for ; Fri, 1 Mar 2002 11:44:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27422; Fri, 1 Mar 2002 11:39:14 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 11:39:14 -0500 (EST) Resent-Message-Id: <200203011639.LAA27422@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 LAA27295 for ; Fri, 1 Mar 2002 11:39:07 -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 LAA21813 for ; Fri, 1 Mar 2002 11:39:07 -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, 01 Mar 2002 11:37:09 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 11:38:35 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AFDF@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 1 Mar 2002 11:38:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id LAA27295 Subject: RE: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5993 X-Loop: w3c-dist-auth@w3.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 You forgot the smiley face around "piece of cake" (:-). Note that getting everyone to agree on a format for embedding headers in URL references is only part the problem (and html is only one of the many locations where URL's might appear). Getting everyone to upgrade their search engines to repeat their requests with the appropriate headers (or using the appropriate variant GET methods) is another part. And given the limited number of resources that will actually support the variant access mechanisms, the cost of re-trying each request with each of the possible variants is also a negating factor. Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Friday, March 01, 2002 9:19 AM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: Re: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect)) Not speaking of the problem how the heck google is to display search results for such source documents... But by then we probably have extended HTML to handle link to interesting source in all browsers. Piece of cake really. //Stefan Am Freitag den, 1. März 2002, um 14:32, schrieb Clemm, Geoff: > The special header would effectively break the ability for Web Search > engines (e.g. google.com) to index the resource space, unless they were > upgraded to re-crawl the URL space with the "Translate" header, and > then store in their cache that the "Translate" header needs to be > included in the request. Analogously, it becomes impossible to just > embed a URL in a mail message that refers someone to the source ... > you'd have to somehow include an annotation that says "and use the > Translate header when you request this URL". These kinds of reasons > make me strongly object to either the GETSRC method or a Translate > header. > > Cheers, > Geoff > > -----Original Message----- > From: Erik Seaberg [mailto:erk@flyingcroc.com] > Sent: Thursday, February 28, 2002 11:41 PM > To: w3c-dist-auth@w3c.org > Subject: Source header instead of property? (was Re: A case for GETSRC > (or other mechanism to that effect)) > > > 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? > > From w3c-dist-auth-request@w3.org Fri Mar 1 11:54: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 LAA05737 for ; Fri, 1 Mar 2002 11:54:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA29092; Fri, 1 Mar 2002 11:50:11 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 11:50:11 -0500 (EST) Resent-Message-Id: <200203011650.LAA29092@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 LAA29059 for ; Fri, 1 Mar 2002 11:49:49 -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 LAA24399 for ; Fri, 1 Mar 2002 11:49:48 -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, 01 Mar 2002 11:47:50 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 11:49:17 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AFE4@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 1 Mar 2002 11:49:16 -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/5994 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Just to keep this thread focused, Jason's assumption is correct that we are all just talking about the comparitive difficulty/benefit of using DAV:source vs. GETSRC (or Translate) in the case where there is a 1-1 mapping. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Friday, March 01, 2002 10:57 AM To: CJ Holmes Cc: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) I didn't understand Julian's response clearly, so I'll take another stab at a response. Firstly I assume the reason that you are discussing difficulty is that you're trying to prove that GETSRC is easier to implement/use than DAV:source. I do agree that GETSRC is probably at least a little easier, but if we're talking about a system where one output resource maps to one source resource, they both are almost the same. (If not, that needs to be proven.) To compare GETSRC handing a 1::1 mapping to DAV:source handing a many:many or many::many mapping of source to output isn't a fair comparison of GETSRC vs DAV:source. That's more a comparison of the complexity of supporting 1::1 vs many::1 mappings. If it's really DAV:source vs GETSRC that you want to compare, you only should be looking at 1::1 mappings. OTOH... if you're not really talking about GETSRC vs DAV:source, but really just talking about the complexity of supporting a 1::1 mapping if you are also supporting a many::many or many::1 mapping, then I think that comparison is more appropriate, but I also think that we haven't clearly defined a protocol that supports many::many yet. As we've pointed out, DAV:source really isn't clearly defined. We don't know what kind of flexibility it will be defined to support so we don't know what kind of burden it creates. Until it's defined, we can't really envision what it's like to support a many::many mapping. I hope we rapidly define how DAV:source supports composition from many underlying resources. Then we do the comparison. Anyway... what I say below assumes you're talking about comparing GETSRC vs DAV:source on a server that just supports 1::1 mappings. If this is not your scenario, please forgive me. > >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 , 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. But in your case of GETSRC you have to do the same thing. If it's hard for one, it's hard for the other. Just because a server supports DAV:source doesn't mean that it's going to put it's data in weird hard-to-find places. It's very likely to put everything physically in the same place a pure GETSRC server would. << 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. >> Having the JSP be DAV-aware is of course a terrible burden, but I don't think anyone is suggesting it needs to be. The mapping would not be done at the JSP layer. And even if it would be, it would be the same mapping that one would use for a pure GETSRC server. << 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. >> That sounds great. But the same would almost certainly be true for a server that supports DAV:source. It doesn't have to be true for such a server, but it doesn't have to be true for a pure GETSRC server either. But it seems reasonable to keep the underlying resource where you've described so both implementations are likely to do it that way. << 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. >> I think these three points are more to the point. This sounds pretty easy and that was half your point. The other half of your point is that it's hard to support DAV:source. I think a supporter of DAV:source would say that they'd just install a filter in Apache for URL's with a magical something in them that distinguishes them and would handle all method calls to those resources. If you want to prove that doing DAV:source is much harder than doing GETSRC, someone still needs to show that doing DAV:source is hard. My intuition tells me it isn't as easy as GETSRC, but that it probably couldn't be described as hard. Again, this is all only for a server that is only supporting 1::1 mappings. Any other type of server isn't clearly defined yet. FWIW... I don't think anyone so far has proposed that a server support GETSRC without supporting DAV:source, so pointing out that GETSRC is easier for a server to implement than DAV:source is a moot point because in the current proposals the servers would implement DAV:source anyway and implementing GETSRC would be an optional extra effort (only?) to offer clients a way to access the source of a resource in single HTTP request rather than having to do a PROPFIND first. Anyway, see my comments at the top of this posting. They might make much of this moot. J. From w3c-dist-auth-request@w3.org Fri Mar 1 13:08:16 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 NAA11026 for ; Fri, 1 Mar 2002 13:08:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06214; Fri, 1 Mar 2002 13:04:02 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 13:04:02 -0500 (EST) Resent-Message-Id: <200203011804.NAA06214@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 NAA06190 for ; Fri, 1 Mar 2002 13:03:55 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA03753 for ; Fri, 1 Mar 2002 13:03:55 -0500 Received: from 10.196.0.11 by mail.4d.com; Fri, 1 Mar 2002 10:03:45 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105F84B0E@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B105F84B0E@SUS-MA1IT01> Date: Fri, 1 Mar 2002 10:03:37 -0800 To: w3c-dist-auth@w3c.org From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5995 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > From: CJ Holmes [mailto:cholmes@4d.com] > > 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. > >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. I agree with all of this! I have no bones whatsoever to pick about the superiority of keeping source and display resources separate, or its happy consequences. For an integrated content management system you would definitely want this, and it would be pretty darn cool. What I disagree with is the _requirement_ to keep the two spaces separate, which burdens administrators with a lot of extra configuration, isn't understood by most content-generation software today (if any), and often confuses the end-users who can barely use Dreamweaver/Golive/FrontPage much less understand why their "browser" URL is different from their "Dreamweaver" URL. For most installations, keeping the URIs the same is a desireable thing and does not cause anyone to lose any functionality that they care about. Most people don't care about indexing their source, and we have specialized crawlers already for indexing display content. I'm just saying that the simple things should be easy. It's a basic rule of design. I'm not stuck on the GETSRC idea. I'll implement Translate almost as happily if that's the direction the group goes. If the group doesn't come up with anything at all, then Translate is likely to become the de-facto standard, and you'll end up putting it into RFC-2518-bis2 anyway. cjh -- From w3c-dist-auth-request@w3.org Fri Mar 1 13:41: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 NAA13602 for ; Fri, 1 Mar 2002 13:41:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA09106; Fri, 1 Mar 2002 13:37:43 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 13:37:43 -0500 (EST) Resent-Message-Id: <200203011837.NAA09106@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 NAA09084 for ; Fri, 1 Mar 2002 13:37:26 -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 NAA09927 for ; Fri, 1 Mar 2002 13:37:26 -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, 01 Mar 2002 13:35:28 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 13:36:55 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AFE9@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 1 Mar 2002 13:36:54 -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/5996 X-Loop: w3c-dist-auth@w3.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 problem with having multiple ways of doing things is that it harms interoperability, when one server does one thing (maintain the DAV:src property) and another server does another (a GETSRC method or a Translate header). Servers are always going to have proprietary extensions, and widely distributed servers (e.g. IIS) are going to have clients coded against those proprietary extensions, but the goal of the standard protocol is to produce an interoperable protocol, which means not providing different alternative ways to produce the same result. Cheers, Geoff -----Original Message----- From: CJ Holmes [mailto:cholmes@4d.com] Sent: Friday, March 01, 2002 1:04 PM To: w3c-dist-auth@w3c.org Subject: RE: A case for GETSRC (or other mechanism to that effect) > From: CJ Holmes [mailto:cholmes@4d.com] > > 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. > >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. I agree with all of this! I have no bones whatsoever to pick about the superiority of keeping source and display resources separate, or its happy consequences. For an integrated content management system you would definitely want this, and it would be pretty darn cool. What I disagree with is the _requirement_ to keep the two spaces separate, which burdens administrators with a lot of extra configuration, isn't understood by most content-generation software today (if any), and often confuses the end-users who can barely use Dreamweaver/Golive/FrontPage much less understand why their "browser" URL is different from their "Dreamweaver" URL. For most installations, keeping the URIs the same is a desireable thing and does not cause anyone to lose any functionality that they care about. Most people don't care about indexing their source, and we have specialized crawlers already for indexing display content. I'm just saying that the simple things should be easy. It's a basic rule of design. I'm not stuck on the GETSRC idea. I'll implement Translate almost as happily if that's the direction the group goes. If the group doesn't come up with anything at all, then Translate is likely to become the de-facto standard, and you'll end up putting it into RFC-2518-bis2 anyway. cjh -- From w3c-dist-auth-request@w3.org Fri Mar 1 14:41: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 OAA19238 for ; Fri, 1 Mar 2002 14:41:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA14885; Fri, 1 Mar 2002 14:35:50 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 14:35:50 -0500 (EST) Resent-Message-Id: <200203011935.OAA14885@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 OAA14852 for ; Fri, 1 Mar 2002 14:35:25 -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 OAA18342 for ; Fri, 1 Mar 2002 14:35:24 -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 LAA84268 for ; Fri, 1 Mar 2002 11:35:23 -0800 (PST) Received: (from erk@localhost) by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g21JX2a22613; Fri, 1 Mar 2002 11:33:02 -0800 (PST) (envelope-from erk) To: w3c-dist-auth@w3c.org In-Reply-To: <3906C56A7BD1F54593344C05BD1374B105F84B44@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B105F84B44@SUS-MA1IT01> From: Erik Seaberg Date: 01 Mar 2002 11:33:02 -0800 Message-ID: <86n0xsnkwh.fsf@unx51.staff.flyingcroc.net> Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: Source header instead of property? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5997 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Oh, I don't mean a Translate-like request header that asks for the source resource at an overloaded URI, just that sending the source URI in a response header could be a smaller burden than having every output resource generator implement PROPFIND just for the sake of answering a request for {DAV:}source for output resources that have no other noteworthy DAV properties. Like so: c> HEAD /cgi-bin/foo.pl?bar=1 HTTP/1.1 c> Host: www.example.com c> Authorization: Basic ZXJrOnBhc3N3b3Jk c> s> HTTP/1.1 200 OK s> Content-Type: text/html s> Source: http://www.example.com/cgi-src/foo.pl s> http://www.example.com/cgi-src/MyClass.pm s> c> GET /cgi-src/foo.pl HTTP/1.1 c> Host: www.example.com c> Authorization: Basic ZXJrOnBhc3N3b3Jk c> s> HTTP/1.1 200 OK s> Content-Type: text/x-perl s> s> #!/usr/bin/perl s> ... From w3c-dist-auth-request@w3.org Fri Mar 1 16:05: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 QAA27737 for ; Fri, 1 Mar 2002 16:05:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA23329; Fri, 1 Mar 2002 16:00:26 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 16:00:26 -0500 (EST) Resent-Message-Id: <200203012100.QAA23329@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 QAA23272 for ; Fri, 1 Mar 2002 16:00:05 -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 QAA28768 for ; Fri, 1 Mar 2002 16:00:04 -0500 Received: by cm-exgw1.filenet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 12:59:30 -0800 Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3c.org, www-webdav-dasl@w3.org Date: Fri, 1 Mar 2002 12:59:29 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5998 X-Loop: w3c-dist-auth@w3.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: SEARH must take a position on spaces. It is a critical issue for string literals. I agree that we're defining a protocol -- something processed by software. The readability of the protocol string is secondary. However, examples are presented in specs., and there is some benefit to having these examples be readable. For many elements, extra whitespace doesn't matter. So including whitespace for such elements is good idea to enhance the presentation of the example in the spec. (but not on the wire). For string literals, however, whitespace is critical. Upon reflection, I agree with you that SEARCH should say that all characters, including all whitespace (i.e., spaces, tabs, carriage returns, vertical form feeds, etc.) in string literals are part of the string literal. Simpler is better. Alan Babich -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, March 01, 2002 3:08 AM To: w3c-dist-auth@w3c.org; www-webdav-dasl@w3.org Subject: xml:space Hi. The WebDAV SEARCH draft currently has an issue regarding treatment of xml:space [1]: it says, that the basicsearch grammer should respect xml:space="default" in a literal element, so that xyz would really be equivalent to: xyz That's compatible with XML, but it's not consistent with WebDAV (which doesn't say anything about xml:space). The only benefit of xml:space for WebDAV I'm aware of is that you could have indented "beautified" message bodies and have the receiver care about whitespace removal. However, as both WebDAV request and response bodies are generated/consumed by code (not human readers), that's hardly important. So my proposal would be: 1) In WebDAV, state that whitespace *is* significant, 2) Drop the feature in WebDAV SEARCH's DAV:literal. Comments? [1] From w3c-dist-auth-request@w3.org Fri Mar 1 16:17:22 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 QAA28624 for ; Fri, 1 Mar 2002 16:17:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA24852; Fri, 1 Mar 2002 16:12:40 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 16:12:40 -0500 (EST) Resent-Message-Id: <200203012112.QAA24852@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 QAA24832 for ; Fri, 1 Mar 2002 16:12:34 -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 QAA30946 for ; Fri, 1 Mar 2002 16:12:32 -0500 Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 13:12:00 -0800 Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3c.org Date: Fri, 1 Mar 2002 13:12:01 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/5999 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Based on basic data modeling considerations, I agree with Julian that the source(s) and the output should not be considered variants of the same resource. Hence, they would seem to require different URI's. Alan Babich -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, March 01, 2002 5:41 AM To: w3c-dist-auth@w3c.org Subject: RE: Source header instead of property? (was Re: A case for GETSR C (or other mechanism to that effect)) Thanks, Geoff. Sorry if I keep repeating myself, but: are the source and the output resource a) different resources, or b) variants of the same resource [1]. I say "a)", and thus they need to have different URIs. Julian [1] RFC2616, section 1.3 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 01, 2002 2:32 PM > To: w3c-dist-auth@w3c.org > Subject: RE: Source header instead of property? (was Re: A case for > GETSR C (or other mechanism to that effect)) > > > The special header would effectively break the ability for Web Search > engines (e.g. google.com) to index the resource space, unless they were > upgraded to re-crawl the URL space with the "Translate" header, and > then store in their cache that the "Translate" header needs to be > included in the request. Analogously, it becomes impossible to just > embed a URL in a mail message that refers someone to the source ... > you'd have to somehow include an annotation that says "and use the > Translate header when you request this URL". These kinds of reasons > make me strongly object to either the GETSRC method or a Translate > header. > > Cheers, > Geoff > > -----Original Message----- > From: Erik Seaberg [mailto:erk@flyingcroc.com] > Sent: Thursday, February 28, 2002 11:41 PM > To: w3c-dist-auth@w3c.org > Subject: Source header instead of property? (was Re: A case for GETSRC > (or other mechanism to that effect)) > > > 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? > From w3c-dist-auth-request@w3.org Fri Mar 1 16: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 QAA00278 for ; Fri, 1 Mar 2002 16:39:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28087; Fri, 1 Mar 2002 16:37:51 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 16:37:51 -0500 (EST) Resent-Message-Id: <200203012137.QAA28087@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 QAA28041 for ; Fri, 1 Mar 2002 16:37:38 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA01475 for ; Fri, 1 Mar 2002 16:37:37 -0500 Received: from 10.196.0.11 by mail.4d.com; Fri, 1 Mar 2002 13:37:35 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AFE9@SUS-MA1IT01> References: <3906C56A7BD1F54593344C05BD1374B103F8AFE9@SUS-MA1IT01> Date: Fri, 1 Mar 2002 13:37:26 -0800 To: w3c-dist-auth@w3.org From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6000 X-Loop: w3c-dist-auth@w3.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 problem with having multiple ways of doing things >is that it harms interoperability, when one server does one thing >(maintain the DAV:src property) and another server does another >(a GETSRC method or a Translate header). Servers are always going >to have proprietary extensions, and widely distributed servers >(e.g. IIS) are going to have clients coded against those proprietary >extensions, but the goal of the standard protocol is to produce an >interoperable protocol, which means not providing different alternative >ways to produce the same result. Ok, let's try a different tack. Let's keep the model that says source and display URIs are different, and keep/fix DAV:source, and leave all that the way it is. Let's just require that DAV clients add a special field to the request so that servers know they are talking to a client that is likely to send MKCOL, PROPFIND, and other DAV-specific methods. That way the URI model stays the same, and servers can tell when a GET request was generated by a DAV client. Servers that only want to provide DAV access to source URIs may do so without creating new URI spaces. Call it DAV-Enabled. The value must be present but is ignored. (If someone got ambitious it could be used by the client to indicate its capabilities. But one problem at a time, OK?) How's that for a solution? cjh -- From w3c-dist-auth-request@w3.org Fri Mar 1 16:43: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 QAA00540 for ; Fri, 1 Mar 2002 16:43:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28387; Fri, 1 Mar 2002 16:41:47 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 16:41:47 -0500 (EST) Resent-Message-Id: <200203012141.QAA28387@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 QAA28354 for ; Fri, 1 Mar 2002 16:41: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 ESMTP id QAA01843 for ; Fri, 1 Mar 2002 16:41: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; Fri, 01 Mar 2002 16:39:35 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 16:41:02 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8AFED@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 1 Mar 2002 16:41:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Source header instead of property? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6001 X-Loop: w3c-dist-auth@w3.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 problem with always sending back such a header when it wasn't explicitly asked for is that the amount of "interesting" information can be very large. That is why we have an explicit "PROPFIND" call, rather than returning all properties every time in headers. Cheers, Geoff -----Original Message----- From: Erik Seaberg [mailto:erk@flyingcroc.com] Sent: Friday, March 01, 2002 2:33 PM To: w3c-dist-auth@w3c.org Subject: Re: Source header instead of property? Oh, I don't mean a Translate-like request header that asks for the source resource at an overloaded URI, just that sending the source URI in a response header could be a smaller burden than having every output resource generator implement PROPFIND just for the sake of answering a request for {DAV:}source for output resources that have no other noteworthy DAV properties. Like so: c> HEAD /cgi-bin/foo.pl?bar=1 HTTP/1.1 c> Host: www.example.com c> Authorization: Basic ZXJrOnBhc3N3b3Jk c> s> HTTP/1.1 200 OK s> Content-Type: text/html s> Source: http://www.example.com/cgi-src/foo.pl s> http://www.example.com/cgi-src/MyClass.pm s> c> GET /cgi-src/foo.pl HTTP/1.1 c> Host: www.example.com c> Authorization: Basic ZXJrOnBhc3N3b3Jk c> s> HTTP/1.1 200 OK s> Content-Type: text/x-perl s> s> #!/usr/bin/perl s> ... From w3c-dist-auth-request@w3.org Fri Mar 1 19:51: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 TAA08381 for ; Fri, 1 Mar 2002 19:51:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA10793; Fri, 1 Mar 2002 19:47:47 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 19:47:47 -0500 (EST) Resent-Message-Id: <200203020047.TAA10793@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 TAA10768 for ; Fri, 1 Mar 2002 19:47:28 -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 TAA23225 for ; Fri, 1 Mar 2002 19:47:27 -0500 Received: (qmail 20011 invoked by uid 0); 2 Mar 2002 00:46:54 -0000 Received: from p50825e6d.dip.t-dialin.net (HELO lisa) (80.130.94.109) by mail.gmx.net (mp005-rz3) with SMTP; 2 Mar 2002 00:46:54 -0000 From: "Julian Reschke" To: "CJ Holmes" , Date: Sat, 2 Mar 2002 01:46:53 +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: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6002 X-Loop: w3c-dist-auth@w3.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: Friday, March 01, 2002 7:04 PM > To: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > > From: CJ Holmes [mailto:cholmes@4d.com] > > > > 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. > > > > >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. > > I agree with all of this! I have no bones whatsoever to pick about > the superiority of keeping source and display resources separate, or > its happy consequences. For an integrated content management system > you would definitely want this, and it would be pretty darn cool. > > What I disagree with is the _requirement_ to keep the two spaces > separate, which burdens administrators with a lot of extra There *is no* requirement to keep the spaces separate, just the individual URIs. For instance, for any given ASP resource "x" you could generate a DAV:source pointing to "x.~source~", and the serve the source code (and accept PUTs on the source code) on that URI. > configuration, isn't understood by most content-generation software > today (if any), and often confuses the end-users who can barely use > Dreamweaver/Golive/FrontPage much less understand why their "browser" > URL is different from their "Dreamweaver" URL. For most That's why the DAV:source property was defined. It enables clients to automatically discover the source URIs (and to offer to edit *them* instead). > installations, keeping the URIs the same is a desireable thing and > does not cause anyone to lose any functionality that they care about. > Most people don't care about indexing their source, and we have > specialized crawlers already for indexing display content. Sorry, but if we can't agree on the simple axiom that different resources need different URIs, there's really not much point debating. Again: do you consider the source and the output to be the same resource? > I'm just saying that the simple things should be easy. It's a basic > rule of design. Yes, but it can be only as simple as reasonable possible. > I'm not stuck on the GETSRC idea. I'll implement Translate almost as > happily if that's the direction the group goes. If the group doesn't That's just a little syntactic difference. Both share the same problems. > come up with anything at all, then Translate is likely to become the > de-facto standard, and you'll end up putting it into RFC-2518-bis2 > anyway. Translate already *is* a de-facto standard, but that doesn't mean it automatically qualifies as acceptable solution. From w3c-dist-auth-request@w3.org Fri Mar 1 20:01: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 UAA08657 for ; Fri, 1 Mar 2002 20:01:52 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12149; Fri, 1 Mar 2002 20:00:58 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 20:00:58 -0500 (EST) Resent-Message-Id: <200203020100.UAA12149@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 UAA12114 for ; Fri, 1 Mar 2002 20:00:50 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA24719 for ; Fri, 1 Mar 2002 20:00:50 -0500 Received: from 10.196.0.11 by mail.4d.com; Fri, 1 Mar 2002 17:00:51 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Fri, 1 Mar 2002 17:00:44 -0800 To: w3c-dist-auth@w3.org From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6004 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Call it DAV-Enabled. The value must be present but is ignored. (If >> someone got ambitious it could be used by the client to indicate its > > capabilities. But one problem at a time, OK?) >> >It doesn't change the issue that you'd be using the same URI for different >resources. That's a very basic problem, and no amount of syntactic sugar >makes it go away. Yeah, but it's OUR problem, and not yours. If our DAV implementation is unsatisfactory to our customers then we have to change it. But this would let us (and other implementors) give our customers what they want, which is DAV access to their source files with virtually no configuration necessary. All we need from the protocol group is a sure way to know that a GET command originated from a DAV client. Is that so much to ask? cjh -- From w3c-dist-auth-request@w3.org Fri Mar 1 20:09: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 UAA08859 for ; Fri, 1 Mar 2002 20:09:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12938; Fri, 1 Mar 2002 20:08:22 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 20:08:22 -0500 (EST) Resent-Message-Id: <200203020108.UAA12938@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 UAA12918 for ; Fri, 1 Mar 2002 20:08:18 -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 UAA25709 for ; Fri, 1 Mar 2002 20:08:18 -0500 Received: (qmail 29519 invoked by uid 0); 2 Mar 2002 01:07:43 -0000 Received: from p50825e6d.dip.t-dialin.net (HELO lisa) (80.130.94.109) by mail.gmx.net (mp005-rz3) with SMTP; 2 Mar 2002 01:07:43 -0000 From: "Julian Reschke" To: "CJ Holmes" , Date: Sat, 2 Mar 2002 02:07:41 +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: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6005 X-Loop: w3c-dist-auth@w3.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: Saturday, March 02, 2002 2:01 AM > To: w3c-dist-auth@w3.org > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > > > Call it DAV-Enabled. The value must be present but is ignored. (If > >> someone got ambitious it could be used by the client to indicate its > > > capabilities. But one problem at a time, OK?) > >> > >It doesn't change the issue that you'd be using the same URI for > different > >resources. That's a very basic problem, and no amount of syntactic sugar > >makes it go away. > > Yeah, but it's OUR problem, and not yours. If our DAV implementation > is unsatisfactory to our customers then we have to change it. But > this would let us (and other implementors) give our customers what > they want, which is DAV access to their source files with virtually > no configuration necessary. > > All we need from the protocol group is a sure way to know that a GET > command originated from a DAV client. Is that so much to ask? To be honest: yes. GET is GET. It doesn't matter what client it comes from. You shouldn't try to change that. From w3c-dist-auth-request@w3.org Fri Mar 1 20:28: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 UAA09216 for ; Fri, 1 Mar 2002 20:28:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA14633; Fri, 1 Mar 2002 20:27:27 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 20:27:27 -0500 (EST) Resent-Message-Id: <200203020127.UAA14633@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 UAA14557 for ; Fri, 1 Mar 2002 20:27:04 -0500 (EST) Received: from waka.wakasoft.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 UAB28209 for ; Fri, 1 Mar 2002 20:27:04 -0500 Received: (from fielding@localhost) by waka.wakasoft.com (8.11.0/8.11.0) id g221N6k03132; Fri, 1 Mar 2002 17:23:06 -0800 Date: Fri, 1 Mar 2002 17:23:06 -0800 From: "Roy T. Fielding" To: CJ Holmes Cc: w3c-dist-auth@w3.org Message-ID: <20020301172306.A3113@waka.wakasoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6006 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > Yeah, but it's OUR problem, and not yours. If our DAV implementation > is unsatisfactory to our customers then we have to change it. But > this would let us (and other implementors) give our customers what > they want, which is DAV access to their source files with virtually > no configuration necessary. No configuration is necessary with dav:source other than what was already done to create the dynamic resource. > All we need from the protocol group is a sure way to know that a GET > command originated from a DAV client. Is that so much to ask? No, the problem is that your question starts off with an awful design decision and expects the WG to validate that through another unnecessary and completely lame hack. A DAV client doesn't do a GET in order to start editing a resource. It MUST, for many reasons, perform a PROPFIND on the resource. When it does that on a resource that is not capable of being edited, such as a dynamic-content resource, it will receive the information necessary to tell the it and the user that to go edit these other URI (as provided by dav:source) in order to modify the content. When the user picks one of those to edit, the client software will then do a PROPFIND on that other URI, and will continue this recursively until it gets to a resource that is static and authorable. There simply is no other way to implement authoring using the Web interface without assuming that everything is a static file, and not assuming that was the whole point of defining a WebDAV protocol in the first place. If editing files was good enough, we'd just us FTP and rsync. ....Roy From w3c-dist-auth-request@w3.org Fri Mar 1 20:39: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 TAA08382 for ; Fri, 1 Mar 2002 19:51:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA10854; Fri, 1 Mar 2002 19:48:58 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 19:48:58 -0500 (EST) Resent-Message-Id: <200203020048.TAA10854@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 TAA10833 for ; Fri, 1 Mar 2002 19:48:46 -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 TAA23341 for ; Fri, 1 Mar 2002 19:48:46 -0500 Received: (qmail 17858 invoked by uid 0); 2 Mar 2002 00:48:12 -0000 Received: from p50825e6d.dip.t-dialin.net (HELO lisa) (80.130.94.109) by mail.gmx.net (mp007-rz3) with SMTP; 2 Mar 2002 00:48:12 -0000 From: "Julian Reschke" To: "CJ Holmes" , Date: Sat, 2 Mar 2002 01:48:11 +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: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6003 X-Loop: w3c-dist-auth@w3.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: Friday, March 01, 2002 10:37 PM > To: w3c-dist-auth@w3.org > Subject: DAV-Enabled field (was RE: A case for GETSRC) > > > >The problem with having multiple ways of doing things > >is that it harms interoperability, when one server does one thing > >(maintain the DAV:src property) and another server does another > >(a GETSRC method or a Translate header). Servers are always going > >to have proprietary extensions, and widely distributed servers > >(e.g. IIS) are going to have clients coded against those proprietary > >extensions, but the goal of the standard protocol is to produce an > >interoperable protocol, which means not providing different alternative > >ways to produce the same result. > > Ok, let's try a different tack. > > Let's keep the model that says source and display URIs are different, > and keep/fix DAV:source, and leave all that the way it is. > > Let's just require that DAV clients add a special field to the > request so that servers know they are talking to a client that is > likely to send MKCOL, PROPFIND, and other DAV-specific methods. > > That way the URI model stays the same, and servers can tell when a > GET request was generated by a DAV client. Servers that only want to > provide DAV access to source URIs may do so without creating new URI > spaces. > > Call it DAV-Enabled. The value must be present but is ignored. (If > someone got ambitious it could be used by the client to indicate its > capabilities. But one problem at a time, OK?) > > How's that for a solution? It doesn't change the issue that you'd be using the same URI for different resources. That's a very basic problem, and no amount of syntactic sugar makes it go away. From w3c-dist-auth-request@w3.org Fri Mar 1 20:58:24 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 UAA09885 for ; Fri, 1 Mar 2002 20:58:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA16753; Fri, 1 Mar 2002 20:57:06 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 20:57:06 -0500 (EST) Resent-Message-Id: <200203020157.UAA16753@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 UAA16706 for ; Fri, 1 Mar 2002 20:56:44 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id UAA30795 for ; Fri, 1 Mar 2002 20:56:44 -0500 Received: from 10.196.1.86 by mail.4d.com; Fri, 1 Mar 2002 17:56:47 -0800 User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 01 Mar 2002 17:58:33 -0800 From: Matthieu Chevrier To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6007 X-Loop: w3c-dist-auth@w3.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 >> All we need from the protocol group is a sure way to know that a GET >> command originated from a DAV client. Is that so much to ask? > > To be honest: yes. > > GET is GET. It doesn't matter what client it comes from. You shouldn't try > to change that. > apart if your company's name is Microsoft, right? Because that's precisely what they did with 'Translate'. It seems like we are pretty much done with this thread. Just want to add one little thing : in the SOAP specifications, POST requests MUST have a SoapAction field. It is not specified what this field should contain, just that it has to be there. And noone complained that it's breaking the holy POST. Soap is of course a completely different protocol compared to DAV, but it's still interesting I believe to think about why the spec writers made this choice (or shall I say a lame hack Roy?) Regards, Matthieu. From w3c-dist-auth-request@w3.org Fri Mar 1 21:39: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 VAA11817 for ; Fri, 1 Mar 2002 21:39:18 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA19211; Fri, 1 Mar 2002 21:36:15 -0500 (EST) Resent-Date: Fri, 1 Mar 2002 21:36:15 -0500 (EST) Resent-Message-Id: <200203020236.VAA19211@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 VAA19186 for ; Fri, 1 Mar 2002 21:35:52 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id VAA01435 for ; Fri, 1 Mar 2002 21:35:52 -0500 Received: from 10.196.0.11 by mail.4d.com; Fri, 1 Mar 2002 18:35:55 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: <20020301172306.A3113@waka.wakasoft.com> References: <20020301172306.A3113@waka.wakasoft.com> Date: Fri, 1 Mar 2002 18:35:41 -0800 To: w3c-dist-auth@w3.org From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6008 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Yeah, but it's OUR problem, and not yours. If our DAV implementation >> is unsatisfactory to our customers then we have to change it. But >> this would let us (and other implementors) give our customers what >> they want, which is DAV access to their source files with virtually >> no configuration necessary. > >No configuration is necessary with dav:source other than what was already >done to create the dynamic resource. I've tried to explain the real-world "hassle for no gain for most people" situation on this about five times now. I'm not going to repeat it because apparently nobody on this list thinks such issues merit much weight. But I guess what administrators have to do to configure their servers or how much we confuse hapless users is inconsequential in the face of the prospect of adding a mote of dust to the pure model of DAV. > > All we need from the protocol group is a sure way to know that a GET >> command originated from a DAV client. Is that so much to ask? > >No, the problem is that your question starts off with an awful design >decision and expects the WG to validate that through another unnecessary >and completely lame hack. It starts with trying to find a way to accommodate users who don't give a darn about using DAV on display resources, and would like to use DAV to edit their sources without screwing with the URL. If it was just a minority of users, it wouldn't be an issue. But it is a majority of users and installations, so it is an issue. Translate exists because it solves this problem by identifying GETs from DAV clients. If we have to use Translate to give our customers what they want, then so be it. I was just hoping we could get something defined by a group of thoughtful people instead of something undocumented. cjh -- From w3c-dist-auth-request@w3.org Sat Mar 2 07:31:18 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 HAA29344 for ; Sat, 2 Mar 2002 07:31:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA23678; Sat, 2 Mar 2002 07:23:05 -0500 (EST) Resent-Date: Sat, 2 Mar 2002 07:23:05 -0500 (EST) Resent-Message-Id: <200203021223.HAA23678@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 HAA23655 for ; Sat, 2 Mar 2002 07:22:51 -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 HAA15678 for ; Sat, 2 Mar 2002 07:22:49 -0500 Received: (qmail 2169 invoked by uid 0); 2 Mar 2002 12:22:15 -0000 Received: from p50825e6d.dip.t-dialin.net (HELO lisa) (80.130.94.109) by mail.gmx.net (mp002-rz3) with SMTP; 2 Mar 2002 12:22:15 -0000 From: "Julian Reschke" To: "CJ Holmes" , Date: Sat, 2 Mar 2002 13:22: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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6009 X-Loop: w3c-dist-auth@w3.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 CJ, I understand your frustration. However, so far you have failed to answer the following question: Are the source and it's output (from an HTTP point of view!) the same resource? If they aren't, they MUST have different URIs. This is a fundamental property of URIs and resources that you just can't throw away because it *seems* to be convenient for you. If you say they are, you'll have to convince us that the source code (of for example an ASP page) and it's output are different representations of the same thing. For instance, let's take the example of an ASP page that creates the list of current bug reports for a certain product "test". It's output is identified by http://server/foo/bugs.asp?product=test It can also be used for other products, so the *different* URI http://server/foo/bugs.asp?product=test2 represents a completely different resource which only happens to be produced by the same script. Finally the script may have a default view (giving a form), which is identified by: http://server/foo/bugs.asp All these resources are different (and thus have different URIs). Let's say that http://server/foo/bugs.asp happens to be WebDAV-compliant resource. When you pass the URL to somebody else, s/he will ultimatively do a GET against it. What GET does is defined in RFC2616, not in WebDAV. As http://server/foo/bugs.asp identifies the *output* of the script, it cannot be used to identify the script itself (otherwise, please show us!). What you *can* do is add a DAV:source property that contains the URI of the actual script (which will actually send the source text upon GET). Some examples are: http://server/foo/bugs.asp?action=send-the-source http://server/foo/?source-of=bugs.asp http://server/foo,source/bugs.asp http://server/sources/foo/bugs.asp http://server:81/foo/bugs.asp and so on. Note that only some of these formats require a second URL namespace / virtual host / port. Finally, please see what the HTTP spec (RFC2616) says in it's first paragraph about GET: "9.3 GET The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process." Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > Sent: Saturday, March 02, 2002 3:36 AM > To: w3c-dist-auth@w3.org > Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) > > > > > Yeah, but it's OUR problem, and not yours. If our DAV implementation > >> is unsatisfactory to our customers then we have to change it. But > >> this would let us (and other implementors) give our customers what > >> they want, which is DAV access to their source files with virtually > >> no configuration necessary. > > > >No configuration is necessary with dav:source other than what was already > >done to create the dynamic resource. > > I've tried to explain the real-world "hassle for no gain for most > people" situation on this about five times now. I'm not going to > repeat it because apparently nobody on this list thinks such issues > merit much weight. But I guess what administrators have to do to > configure their servers or how much we confuse hapless users is > inconsequential in the face of the prospect of adding a mote of dust > to the pure model of DAV. > > > > All we need from the protocol group is a sure way to know that a GET > >> command originated from a DAV client. Is that so much to ask? > > > >No, the problem is that your question starts off with an awful design > >decision and expects the WG to validate that through another unnecessary > >and completely lame hack. > > It starts with trying to find a way to accommodate users who don't > give a darn about using DAV on display resources, and would like to > use DAV to edit their sources without screwing with the URL. If it > was just a minority of users, it wouldn't be an issue. But it is a > majority of users and installations, so it is an issue. > > Translate exists because it solves this problem by identifying GETs > >from DAV clients. If we have to use Translate to give our customers > what they want, then so be it. I was just hoping we could get > something defined by a group of thoughtful people instead of > something undocumented. > > > cjh > > -- > From w3c-dist-auth-request@w3.org Sat Mar 2 10:58:24 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 KAA01645 for ; Sat, 2 Mar 2002 10:58:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA04376; Sat, 2 Mar 2002 10:57:12 -0500 (EST) Resent-Date: Sat, 2 Mar 2002 10:57:12 -0500 (EST) Resent-Message-Id: <200203021557.KAA04376@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 KAA04351 for ; Sat, 2 Mar 2002 10:56:53 -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 KAA29510 for ; Sat, 2 Mar 2002 10:56:54 -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, 02 Mar 2002 10:54:54 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 10:56:23 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B105F84DA8@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Sat, 2 Mar 2002 10:56:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6010 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Any analogy with POST is not very compelling. POST started with vaguely defined semantics, and got vaguer. GET has always had reasonably well defined semantics, i.e. return the content of the resource identified by the specified URL. Cheers, Geoff -----Original Message----- From: Matthieu Chevrier [mailto:mchevrier@4d.com] Sent: Friday, March 01, 2002 8:59 PM To: w3c-dist-auth@w3.org Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) >> All we need from the protocol group is a sure way to know that a GET >> command originated from a DAV client. Is that so much to ask? > > To be honest: yes. > > GET is GET. It doesn't matter what client it comes from. You shouldn't try > to change that. > apart if your company's name is Microsoft, right? Because that's precisely what they did with 'Translate'. It seems like we are pretty much done with this thread. Just want to add one little thing : in the SOAP specifications, POST requests MUST have a SoapAction field. It is not specified what this field should contain, just that it has to be there. And noone complained that it's breaking the holy POST. Soap is of course a completely different protocol compared to DAV, but it's still interesting I believe to think about why the spec writers made this choice (or shall I say a lame hack Roy?) Regards, Matthieu. From w3c-dist-auth-request@w3.org Sat Mar 2 16:36: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 QAA05560 for ; Sat, 2 Mar 2002 16:36:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA29094; Sat, 2 Mar 2002 16:34:19 -0500 (EST) Resent-Date: Sat, 2 Mar 2002 16:34:19 -0500 (EST) Resent-Message-Id: <200203022134.QAA29094@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 QAA29074 for ; Sat, 2 Mar 2002 16:34:12 -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 QAA31410 for ; Sat, 2 Mar 2002 16:34:10 -0500 Received: by hq-exgw2.filenet.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 13:33:37 -0800 Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3.org Date: Sat, 2 Mar 2002 13:33:40 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6011 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: CJ Holmes, Julian: There are various ways to approach this problem. Since it is a data modeling problem, the correct way is to approach it from a data modeling perspective. We are unlikely to end up with the best data model if the problem is approached in some other way. The most fundamental question from a data modeling perspective is the following: "Is the source the same entity as its output?" Julian and I agree that it is not. RFC2616 section 9.3 says it is not. Julian has provided examples below, including the case of multiple outputs from the same source supporting that position. Once there is agreement on this most-basic-point-of-all, it becomes appropriate to move forward and address other concerns. This basic point must be addressed first, before anything else. Alan Babich -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, March 02, 2002 4:22 AM To: CJ Holmes; w3c-dist-auth@w3.org Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) CJ, I understand your frustration. However, so far you have failed to answer the following question: Are the source and it's output (from an HTTP point of view!) the same resource? If they aren't, they MUST have different URIs. This is a fundamental property of URIs and resources that you just can't throw away because it *seems* to be convenient for you. If you say they are, you'll have to convince us that the source code (of for example an ASP page) and it's output are different representations of the same thing. For instance, let's take the example of an ASP page that creates the list of current bug reports for a certain product "test". It's output is identified by http://server/foo/bugs.asp?product=test It can also be used for other products, so the *different* URI http://server/foo/bugs.asp?product=test2 represents a completely different resource which only happens to be produced by the same script. Finally the script may have a default view (giving a form), which is identified by: http://server/foo/bugs.asp All these resources are different (and thus have different URIs). Let's say that http://server/foo/bugs.asp happens to be WebDAV-compliant resource. When you pass the URL to somebody else, s/he will ultimatively do a GET against it. What GET does is defined in RFC2616, not in WebDAV. As http://server/foo/bugs.asp identifies the *output* of the script, it cannot be used to identify the script itself (otherwise, please show us!). What you *can* do is add a DAV:source property that contains the URI of the actual script (which will actually send the source text upon GET). Some examples are: http://server/foo/bugs.asp?action=send-the-source http://server/foo/?source-of=bugs.asp http://server/foo,source/bugs.asp http://server/sources/foo/bugs.asp http://server:81/foo/bugs.asp and so on. Note that only some of these formats require a second URL namespace / virtual host / port. Finally, please see what the HTTP spec (RFC2616) says in it's first paragraph about GET: "9.3 GET The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process." Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > Sent: Saturday, March 02, 2002 3:36 AM > To: w3c-dist-auth@w3.org > Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) > > > > > Yeah, but it's OUR problem, and not yours. If our DAV implementation > >> is unsatisfactory to our customers then we have to change it. But > >> this would let us (and other implementors) give our customers what > >> they want, which is DAV access to their source files with virtually > >> no configuration necessary. > > > >No configuration is necessary with dav:source other than what was already > >done to create the dynamic resource. > > I've tried to explain the real-world "hassle for no gain for most > people" situation on this about five times now. I'm not going to > repeat it because apparently nobody on this list thinks such issues > merit much weight. But I guess what administrators have to do to > configure their servers or how much we confuse hapless users is > inconsequential in the face of the prospect of adding a mote of dust > to the pure model of DAV. > > > > All we need from the protocol group is a sure way to know that a GET > >> command originated from a DAV client. Is that so much to ask? > > > >No, the problem is that your question starts off with an awful design > >decision and expects the WG to validate that through another unnecessary > >and completely lame hack. > > It starts with trying to find a way to accommodate users who don't > give a darn about using DAV on display resources, and would like to > use DAV to edit their sources without screwing with the URL. If it > was just a minority of users, it wouldn't be an issue. But it is a > majority of users and installations, so it is an issue. > > Translate exists because it solves this problem by identifying GETs > >from DAV clients. If we have to use Translate to give our customers > what they want, then so be it. I was just hoping we could get > something defined by a group of thoughtful people instead of > something undocumented. > > > cjh > > -- > From w3c-dist-auth-request@w3.org Sun Mar 3 09:11:42 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 JAA23766 for ; Sun, 3 Mar 2002 09:11:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA23877; Sun, 3 Mar 2002 09:09:36 -0500 (EST) Resent-Date: Sun, 3 Mar 2002 09:09:36 -0500 (EST) Resent-Message-Id: <200203031409.JAA23877@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 JAA23792 for ; Sun, 3 Mar 2002 09:09:10 -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 JAA15006 for ; Sun, 3 Mar 2002 09:09:10 -0500 Received: (qmail 24841 invoked by uid 0); 3 Mar 2002 14:08:36 -0000 Received: from pd95352c8.dip.t-dialin.net (HELO lisa) (217.83.82.200) by mail.gmx.net (mp007-rz3) with SMTP; 3 Mar 2002 14:08:36 -0000 From: "Julian Reschke" To: "Babich, Alan" , , Date: Sun, 3 Mar 2002 15:08: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: space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6012 X-Loop: w3c-dist-auth@w3.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: www-webdav-dasl-request@w3.org > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Babich, Alan > Sent: Friday, March 01, 2002 9:59 PM > To: w3c-dist-auth@w3c.org; www-webdav-dasl@w3.org > Subject: RE: space > > > Julian: > > SEARH must take a position on spaces. It is a critical > issue for string literals. I agree that we're defining a > protocol -- something processed by software. The readability > of the protocol string is secondary. However, examples are > presented in specs., and there is some benefit to having > these examples be readable. For many elements, extra > whitespace doesn't matter. So including whitespace for > such elements is good idea to enhance the presentation > of the example in the spec. (but not on the wire). For > string literals, however, whitespace is critical. > > Upon reflection, I agree with you that SEARCH should say > that all characters, including all whitespace (i.e., spaces, > tabs, carriage returns, vertical form feeds, etc.) in string > literals are part of the string literal. Thanks, Alan. Just for the record: you can't have any control characters except TAB, CR and LF in an XML string (and preservation of the type of line break is not guaranteed). Julian From w3c-dist-auth-request@w3.org Sun Mar 3 14:49: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 OAA28921 for ; Sun, 3 Mar 2002 14:49:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06427; Sun, 3 Mar 2002 14:48:56 -0500 (EST) Resent-Date: Sun, 3 Mar 2002 14:48:56 -0500 (EST) Resent-Message-Id: <200203031948.OAA06427@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 OAA06400 for ; Sun, 3 Mar 2002 14:48:33 -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 OAA11463 for ; Sun, 3 Mar 2002 14:48:32 -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 LAA46085 for ; Sun, 3 Mar 2002 11:48:10 -0800 (PST) Received: (from erk@localhost) by unx51.staff.flyingcroc.net (8.11.6/8.11.6) id g23Jjqa64383; Sun, 3 Mar 2002 11:45:52 -0800 (PST) (envelope-from erk) To: w3c-dist-auth@w3c.org In-Reply-To: References: From: Erik Seaberg Date: 03 Mar 2002 11:45:52 -0800 Message-ID: <86664dtoy7.fsf@unx51.staff.flyingcroc.net> Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.7 Subject: Re: space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6013 X-Loop: w3c-dist-auth@w3.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: > Just for the record: you can't have any control characters except > TAB, CR and LF in an XML string (and preservation of the type of > line break is not guaranteed). Preservation is forbidden, since parsers are required to replace unencoded CRLF or CR in an XML document (or other external parsed entity) with LF. AFAIK you can use to embed a CR in a search string, and it might be safest to encourage clients to avoid line breaks in search strings and use and/or rather than rely on every XML parser to handle line breaks correctly. From w3c-dist-auth-request@w3.org Sun Mar 3 14:56: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 OAA28983 for ; Sun, 3 Mar 2002 14:56:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA06747; Sun, 3 Mar 2002 14:55:36 -0500 (EST) Resent-Date: Sun, 3 Mar 2002 14:55:36 -0500 (EST) Resent-Message-Id: <200203031955.OAA06747@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 OAA06723 for ; Sun, 3 Mar 2002 14:55: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 OAA11944 for ; Sun, 3 Mar 2002 14:55:23 -0500 Received: (qmail 3048 invoked by uid 0); 3 Mar 2002 19:54:48 -0000 Received: from pd95352c8.dip.t-dialin.net (HELO lisa) (217.83.82.200) by mail.gmx.net (mp006-rz3) with SMTP; 3 Mar 2002 19:54:48 -0000 From: "Julian Reschke" To: Date: Sun, 3 Mar 2002 20:54:45 +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: <86664dtoy7.fsf@unx51.staff.flyingcroc.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6014 X-Loop: w3c-dist-auth@w3.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 Erik Seaberg > Sent: Sunday, March 03, 2002 8:46 PM > To: w3c-dist-auth@w3c.org > Subject: Re: space > > > Julian Reschke writes: > > > Just for the record: you can't have any control characters except > > TAB, CR and LF in an XML string (and preservation of the type of > > line break is not guaranteed). > > Preservation is forbidden, since parsers are required to replace > unencoded CRLF or CR in an XML document (or other external parsed > entity) with LF. AFAIK you can use to embed a CR in a search > string, and it might be safest to encourage clients to avoid line > breaks in search strings and use and/or rather than rely > on every XML parser to handle line breaks correctly. Just ti make sure everbody is aware of this: this is a basic limitation of XML character content und thus restricts the possible contents of all (text-based) WebDAV properties. From w3c-dist-auth-request@w3.org Mon Mar 4 05:00:42 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 FAA18432 for ; Mon, 4 Mar 2002 05:00:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA25777; Mon, 4 Mar 2002 04:59:33 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 04:59:33 -0500 (EST) Resent-Message-Id: <200203040959.EAA25777@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 EAA25661 for ; Mon, 4 Mar 2002 04:59:00 -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 EAA23729 for ; Mon, 4 Mar 2002 04:58:59 -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 g24A04Q14295 for ; Mon, 4 Mar 2002 02:00:05 -0800 (PST) Received: from maileurope-ham.eur.adobe.com (maileurope-ham.eur.adobe.com [130.248.122.251]) by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id g249v0Y07093 for ; Mon, 4 Mar 2002 01:57:01 -0800 (PST) Received: from biederichfpc ([130.248.122.32]) by maileurope-ham.eur.adobe.com (Netscape Messaging Server 4.15 ham Jul 11 2001 16:32:57) with SMTP id GSG11A00.JRK; Mon, 4 Mar 2002 10:58:22 +0100 From: "Frank Biederich" To: "Lisa Dusseault" , "'WebDAV'" Date: Mon, 4 Mar 2002 10:58:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <001101c1c0bb$19a25190$7801a8c0@moose> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id EAA25661 Subject: RE: Shared locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6015 X-Loop: w3c-dist-auth@w3.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 - > Frank, have you tested interoperability of shared locks with the Xythos > Sharemation server? What servers have you been able to create shared locks > on? as far as I know, GoLive wasn't even able to connect to the Xythos server during the last interoperability test (Oct 2001). But I know, we're able to set shared locks on IIS and Apache (mod_dav). > We'd only need one more interoperable client to be able to keep shared locks > as we go forward. Is there any solution/workflow implemented upon shared locks? Currently we're using the exclusive locking scheme only, even within our new workgroup system in GoLive 6. So, our Adobe Web Workgroup Server doesn't support shared locks either. Best, Frank > 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 Mon Mar 4 12:58:15 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 MAA06168 for ; Mon, 4 Mar 2002 12:58:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA28324; Mon, 4 Mar 2002 12:52:23 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 12:52:23 -0500 (EST) Resent-Message-Id: <200203041752.MAA28324@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 MAA28295 for ; Mon, 4 Mar 2002 12:52:15 -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 MAA13262 for ; Mon, 4 Mar 2002 12:52:14 -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 JAA00704; Mon, 4 Mar 2002 09:52:10 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Cc: Date: Mon, 4 Mar 2002 09:52:25 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: COPY-Method over the Web Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6016 X-Loop: w3c-dist-auth@w3.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. -----Original Message----- From: Lars Thielemann [mailto:lt@ap-ag.com] Sent: Wednesday, February 27, 2002 6:33 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] COPY-Method over the Web Hi, I have a question to DAV COPY-Method. Is it's possible to copy a resource from a web to another web on the same server? Regards, Lars From w3c-dist-auth-request@w3.org Mon Mar 4 13:23: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 NAA07769 for ; Mon, 4 Mar 2002 13:23:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA00273; Mon, 4 Mar 2002 13:18:52 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 13:18:52 -0500 (EST) Resent-Message-Id: <200203041818.NAA00273@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 NAA00253 for ; Mon, 4 Mar 2002 13:18:39 -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 NAA18189 for ; Mon, 4 Mar 2002 13:18:39 -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 KAA11186; Mon, 4 Mar 2002 10:18:40 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Cc: Date: Mon, 4 Mar 2002 10:18:55 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Re: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6017 X-Loop: w3c-dist-auth@w3.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. - Jim -----Original Message----- From: Roy T. Fielding [mailto:fielding@apache.org] Sent: Thursday, February 28, 2002 2:28 PM To: w3c-dist-auth@w3c.org Subject: [Moderator Action] Re: A case for GETSRC (or other mechanism to that effect) On Thu, Feb 28, 2002 at 09:04:25AM -0500, Clemm, Geoff wrote: > 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. Just in case anyone here has forgotten my vehement objections to GETSRC, let me make it perfectly clear. I will personally veto any attempt to violate one of the primary principles of the Web architecture within the Apache httpd server. We will not implement GETSRC or anything like it. That is just too bad of an idea to allow it to be further propagated. I've already stated my reasons for why it doesn't belong in any protocol related to the Web, and while I cannot control what the WG decides to put in the standard for WebDAV, I will exercise my right not to implement it. We will not implement the Translate header field either, except where necessary to preserve bugward compatibility with deployed clients. Any server that allows clients to vary GET responses based on the Translate header field MUST include "Vary: Translate" in every response to the GET method in order to remain compliant with HTTP/1.1. Since Microsoft is too lazy to implement Vary properly in their client libraries, the effect would be to disable client-side caching of all DAV-authorable resources. The source property is the only mechanism I know of that truly allows the Web interface to be used for authoring of the source resources of dynamically generated content. It does not mean that the server keeps track of the C files of a compiled handler -- that would be ridiculous. What it means is that the server will not allow a client to directly PUT to a resource that is dynamically generated, and the dav:source property should simply list the URL(s) that make up the authorable components of that resource (whether that be negotiated variants, SSI-included components, site-wide header/footers, or external source trees). It is a level of redirection that is necessary to preserve the semantics of the Web interface. Quite frankly, if a person cannot implement that in a trivial amount of time then I'd like to know how their Web server manages to generate the dynamic content in the first place. WebDAV cannot move this feature into another specification. Without it, the protocol is nothing more than a crippled FTP and has no business being a proposed standard. Sincerely, Roy T. Fielding, co-founder, Apache HTTP Server Project (fielding@apache.org) From w3c-dist-auth-request@w3.org Mon Mar 4 15:11: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 PAA18593 for ; Mon, 4 Mar 2002 15:11:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17025; Mon, 4 Mar 2002 15:06:04 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 15:06:04 -0500 (EST) Resent-Message-Id: <200203042006.PAA17025@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 PAA16999 for ; Mon, 4 Mar 2002 15:05:46 -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 PAA04391 for ; Mon, 4 Mar 2002 15:05:46 -0500 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail2.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g24K5hI00466 for ; Mon, 4 Mar 2002 12:05:43 -0800 (PST) Received: from esedlarpc (esedlar-pc-xdsl.us.oracle.com [152.68.17.154]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g24K5cV00676 for ; Mon, 4 Mar 2002 13:05:38 -0700 (MST) From: "Eric Sedlar" To: Date: Mon, 4 Mar 2002 12:05:23 -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) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8AFE4@SUS-MA1IT01> Importance: Normal 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/6018 X-Loop: w3c-dist-auth@w3.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, the issue is not a 1-1 mapping, since GETSRC can handle a many to 1 mapping (many output resources for one source). It just doesn't handle the case of multiple sources for one output resource. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 01, 2002 8:49 AM > To: w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > Just to keep this thread focused, Jason's assumption is correct that we > are all just talking about the comparitive difficulty/benefit of using > DAV:source vs. GETSRC (or Translate) in the case where there is a 1-1 > mapping. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Friday, March 01, 2002 10:57 AM > To: CJ Holmes > Cc: Clemm, Geoff; w3c-dist-auth@w3c.org > Subject: RE: A case for GETSRC (or other mechanism to that effect) > > > > I didn't understand Julian's response clearly, so I'll take > another stab at > a response. > > Firstly I assume the reason that you are discussing difficulty is that > you're > trying to prove that GETSRC is easier to implement/use than DAV:source. > I do agree that GETSRC is probably at least a little easier, but if we're > talking about a system where one output resource maps to one source > resource, they both are almost the same. (If not, that needs to be > proven.) > To compare GETSRC handing a 1::1 mapping to DAV:source handing a > many:many or many::many mapping of source to output isn't a fair > comparison of GETSRC vs DAV:source. That's more a comparison > of the complexity of supporting 1::1 vs many::1 mappings. If it's really > DAV:source vs GETSRC that you want to compare, you only should be > looking at 1::1 mappings. > > OTOH... if you're not really talking about GETSRC vs DAV:source, but > really just talking about the complexity of supporting a 1::1 mapping if > you are also supporting a many::many or many::1 mapping, then I think that > comparison is more appropriate, but I also think that we haven't clearly > defined > a protocol that supports many::many yet. As we've pointed out, DAV:source > really isn't clearly defined. We don't know what kind of flexibility it > will be defined > to support so we don't know what kind of burden it creates. Until it's > defined, we > can't really envision what it's like to support a many::many mapping. I > hope > we rapidly define how DAV:source supports composition from many underlying > resources. Then we do the comparison. > > Anyway... what I say below assumes you're talking about comparing GETSRC > vs DAV:source on a server that just supports 1::1 mappings. If this is > not > your scenario, please forgive me. > > > > >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 , 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. > But in your case of GETSRC you have to do the same thing. If it's > hard for one, it's hard for the other. Just because a server > supports DAV:source doesn't mean that it's going to put it's > data in weird hard-to-find places. It's very likely to put > everything physically in the same place a pure GETSRC server > would. > > > << > 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. > >> > Having the JSP be DAV-aware is of course a terrible burden, but I > don't think anyone is suggesting it needs to be. The mapping would > not be done at the JSP layer. And even if it would be, it would > be the same mapping that one would use for a pure GETSRC server. > > > << > 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. > >> > That sounds great. But the same would almost certainly be true for > a server that supports DAV:source. It doesn't have to be true for > such a server, but it doesn't have to be true for a pure GETSRC > server either. But it seems reasonable to keep the underlying > resource where you've described so both implementations are likely > to do it that way. > > > << > 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. > >> > I think these three points are more to the point. This sounds pretty > easy and that was half your point. The other half of your point is that > it's hard to support DAV:source. I think a supporter of DAV:source would > say that they'd just install a filter in Apache for URL's with a magical > something in them that distinguishes them and would handle all > method calls > to those resources. If you want to prove that > doing DAV:source is much harder than doing GETSRC, someone still needs to > show that doing DAV:source is hard. My intuition tells me it isn't > as easy as GETSRC, but that it probably couldn't be described as hard. > > Again, this is all only for a server that is only supporting 1::1 > mappings. > Any other type of server isn't clearly defined yet. > > > FWIW... I don't think anyone so far has proposed that a server support > GETSRC without supporting DAV:source, so pointing out that GETSRC is > easier for a server to implement than DAV:source is a moot point > because in the current proposals the servers would implement DAV:source > anyway and implementing GETSRC would be an optional extra effort (only?) > to offer clients a way to access the source of a resource in single HTTP > request rather than having to do a PROPFIND first. > > Anyway, see my comments at the top of this posting. They might make much > of this moot. > > J. > > From w3c-dist-auth-request@w3.org Mon Mar 4 16:59: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 QAA25885 for ; Mon, 4 Mar 2002 16:59:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA29800; Mon, 4 Mar 2002 16:54:05 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 16:54:05 -0500 (EST) Resent-Message-Id: <200203042154.QAA29800@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 QAA29729 for ; Mon, 4 Mar 2002 16:53:40 -0500 (EST) Received: from rgminet2.oracle.com (rgminet2.oracle.com [148.87.122.31]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA01229 for ; Mon, 4 Mar 2002 14:48:23 -0500 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.191.10]) by rgminet2.oracle.com (Switch-2.1.4/Switch-2.1.0) with ESMTP id g24JlNT23466; Mon, 4 Mar 2002 12:47:23 -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 g24JmLI02321; Mon, 4 Mar 2002 12:48:21 -0700 (MST) From: "Eric Sedlar" To: "Julian Reschke" , "CJ Holmes" , Date: Mon, 4 Mar 2002 11:48:07 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6019 X-Loop: w3c-dist-auth@w3.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's not clear to me that the generated output from GET on executables actually is a different resource. First of all, it doesn't make sense to think of it as having properties separate from that of the script. I doubt if anyone actually doing the URL space mapping proposed would keep around a set of dead properties for the generated output, but the case becomes clearer when looking at the live properties. If I have a directory full of .ASPs, or .JSP files, and I do a PROPFIND on that directory, will the server actually execute all of the scripts in the directory in order, dumping their output to a temp file, to ensure that dav:getcontentlength is correct? I bet nobody actually does that (it would be "considered harmful" like PROPFIND depth infinity), and if you did it would be stupid. I haven't checked this, but I bet that most servers return the length of the underlying script as the length of the generated output on a PROPFIND depth 1. The same difficulties apply to and many other live properties. The reason this doesn't matter in practice is that returning the wrong etag or wrong content length for generated output is irrelevant, since in the general case it cannot be cached, and it works functionally just as if the resource was changed before the subsequent GET, so it's ok if the value of is different in a PROPFIND on its parent and the actual content length returned when you do a GET. I think that the better model is if you think of the GET method more like the "OPEN" action on Windows or Macintosh, which means to execute this file if executable, or else display the contents of the document. GET is really like a simple case of the POST method (which was originally how it was conceived). To illustrate this point, let's say that a particular server said that POST on a non-executable resource (like a static file) would dump its contents (like a GET). Now we can clearly see GET on a script as a simple case of POST. Julian's argument below gets at the heart of the problem--is each set of possible output generated by a script a different resource? First of all, there are many different things that can affect the output of a resource, and most of them are not in the URL (which is the only thing that can be used to differentiate two resources). While the URL arguments in the query string are one set of arguments to the script, clearly information in the header may also be used (even in a GET method). For example, the authentication headers may be used to choose whose shopping cart will be displayed, or in POST, the form values appear in headers. If, as Julian suggests: GET /foo/my.jsp?arg1=val1 is a different resource than GET /foo/my.jsp?arg1=val2, then POST /foo/my.jsp with a header Arg1: val1 should be different than POST /foo/my.jsp with header Arg1: val2. This obviously makes no sense. So, here are my arguments for why each possible output generated by a script should not be a separate resource: * they may not have separate URLs, since not all of the arguments that cause different output may be in the URL string--they may be in headers, or may depend on other server state * it is impractical to manage dead properties for each possible output * it is computationally difficult to return dead properties (such as dav:getcontentlength) for each possible output Therefore, I conclude that generated output is not a resource, and especially not a dav-enabled resource. I would recommend that server implementers NOT return script output as dav enabled. Now, on to the practical argument, which will demonstrate that dav:source is a lot less usable than GETSRC/Translate: let's say that I have a directory full of scripts and static files. I want to manage them from a authoring point of view. If I want to implement dav:source, I need to create some virtual URL space that corresponds to the physical URL space where the actual script source is stored. I can make the virtual URL space return either the generated output, or the source, at least from an implementation point of view. For example: Contents of /mydir: foo.jsp bar.html bar.gif In case 1, let's say I make /scripts/src/ a virtual URL space that returns the source of any executables (for DAV clients), so where GET /mydir/foo.jsp will return the generated output, /scripts/src/mydir/foo.jsp will return the source. dav:source on /mydir/foo.jsp will point to /scripts/src/mydir/foo.jsp. The DAV client doesn't actually want to mess with /mydir/foo.jsp since it is generated, has bogus live property values, doesn't respond to things like PUT, and is generally not very helpful. Now I'm forced into a separate tree, which is certainly annoying from a useability point of view, and extremely annoying when doing things like copying with Web Folders, since when I drag & drop my app from the local filesystem to the server, my .jsp files move to another place, and when I copy the application back down to my local PC, the .jsps were moved (even if I was smart enough to realize where they magically went to). So, this is a bad solution. In case 2, let's say I make /script/output/ a virtual URL space that returns the generated output for the executables. Now the DAV client is happy, since the server space looks like the space on the client. Unfortunately, all of the tags in any HTML output are screwed up vs. the local copy (e.g if bar.html wanted a link to foo.jsp, or vice versa), since neither a relative nor an absolute URL will work, and the URLs needed are server implementation-dependent. The reality of the world is that people want to be able to move their content creation environment back and forth between local filesystems and DAV servers. Any usage of dav:source would break that abstraction, since local filesystems aren't capable of implementing virtual URL spaces. I think these are the practical reasons why nobody has implemented dav:source in the past 3 years. So, it is clear that: * generated output (from stuff like .jsps, .asps, cgi) does not make sense as a DAV-enabled resource, since the only methods it is likely to respond to intelligently is GET. * separating the URL space of generated output and source causes usability problems, making life awkward either for the DAV client, or for the HTML linking I think the argument for a GETSRC method becomes clear if you mentally rename GET to LIMITED-VERSION-OF-POST. Reponses to a couple of other points in more recent emails: Alan Babich says: "Is the source the same entity as its output?" Julian and I agree that it is not. RFC2616 section 9.3 says it is not. Response: the issue is not whether or not the source and the output are the same "entity", but the same DAV resource. Entity and resource are different things. There are three general categories of things that can cause the output of a generated script to vary: URL information, e.g. the query string; header information; or server-state (like in a database). Clearly the URL isn't sufficient to differentiate between all the kinds of server-generated output, so the various entities that can be generated by a script cannot be mapped as separate resources, since they won't have separate URLs. Roy Fielding says: Any server that allows clients to vary GET responses based on the Translate header field MUST include "Vary: Translate" in every response to the GET method in order to remain compliant with HTTP/1.1. Response: Actually, RFC2616 says: "An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation." So, clearly, Microsoft is in compliance with the HTTP specification since this is not a MUST requirement. Clearly it is acceptable to use header values to vary the content of generated state, whether it be the Translate header or the Authentication header, and whether or not the Vary header is supplied is a completely orthogonal issue. Here's another way to look at the categorization of response entities for executables: 1) the source 2) generated output that does not vary based on input arguments from client 3) generated output varying with input arguments from client encoded in query string 4) generated output varying with input arguments from client encoded in request headers 5) generated output varying with server-side state (like information in a database) I don't see why case #2 and case #3 (in Julian's example) should be awarded its own status as a "real dav resource" when cases #4 and #5 are not. I'd like to see someone propose a scheme for implementing dav:source that solves the usability problem when mapping to the local filesystem, if they believe in dav:source. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Saturday, March 02, 2002 4:22 AM > To: CJ Holmes; w3c-dist-auth@w3.org > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > CJ, > > I understand your frustration. > > However, > > so far you have failed to answer the following question: > > Are the source and it's output (from an HTTP point of view!) the same > resource? If they aren't, they MUST have different URIs. This is a > fundamental property of URIs and resources that you just can't throw away > because it *seems* to be convenient for you. > > If you say they are, you'll have to convince us that the source > code (of for > example an ASP page) and it's output are different representations of the > same thing. > > For instance, let's take the example of an ASP page that creates > the list of > current bug reports for a certain product "test". It's output is > identified > by > > http://server/foo/bugs.asp?product=test > > It can also be used for other products, so the *different* URI > > http://server/foo/bugs.asp?product=test2 > > represents a completely different resource which only happens to > be produced > by the same script. Finally the script may have a default view (giving a > form), which is identified by: > > http://server/foo/bugs.asp > > All these resources are different (and thus have different URIs). > > Let's say that http://server/foo/bugs.asp happens to be WebDAV-compliant > resource. When you pass the URL to somebody else, s/he will > ultimatively do > a GET against it. What GET does is defined in RFC2616, not in WebDAV. As > > http://server/foo/bugs.asp > > identifies the *output* of the script, it cannot be used to identify the > script itself (otherwise, please show us!). > > What you *can* do is add a DAV:source property that contains the > URI of the > actual script (which will actually send the source text upon GET). Some > examples are: > > http://server/foo/bugs.asp?action=send-the-source > > http://server/foo/?source-of=bugs.asp > > http://server/foo,source/bugs.asp > > http://server/sources/foo/bugs.asp > > http://server:81/foo/bugs.asp > > and so on. Note that only some of these formats require a second URL > namespace / virtual host / port. > > > Finally, please see what the HTTP spec (RFC2616) says in it's first > paragraph about GET: > > "9.3 GET > > The GET method means retrieve whatever information (in the form of an > entity) is identified by the Request-URI. > If the Request-URI refers to a data-producing process, it is the produced > data which shall be returned as the entity > in the response and not the source text of the process, unless that text > happens to be the output of the process." > > > Julian > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > > Sent: Saturday, March 02, 2002 3:36 AM > > To: w3c-dist-auth@w3.org > > Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) > > > > > > > > Yeah, but it's OUR problem, and not yours. If our DAV > implementation > > >> is unsatisfactory to our customers then we have to change it. But > > >> this would let us (and other implementors) give our customers what > > >> they want, which is DAV access to their source files with virtually > > >> no configuration necessary. > > > > > >No configuration is necessary with dav:source other than what > was already > > >done to create the dynamic resource. > > > > I've tried to explain the real-world "hassle for no gain for most > > people" situation on this about five times now. I'm not going to > > repeat it because apparently nobody on this list thinks such issues > > merit much weight. But I guess what administrators have to do to > > configure their servers or how much we confuse hapless users is > > inconsequential in the face of the prospect of adding a mote of dust > > to the pure model of DAV. > > > > > > All we need from the protocol group is a sure way to know > that a GET > > >> command originated from a DAV client. Is that so much to ask? > > > > > >No, the problem is that your question starts off with an awful design > > >decision and expects the WG to validate that through another > unnecessary > > >and completely lame hack. > > > > It starts with trying to find a way to accommodate users who don't > > give a darn about using DAV on display resources, and would like to > > use DAV to edit their sources without screwing with the URL. If it > > was just a minority of users, it wouldn't be an issue. But it is a > > majority of users and installations, so it is an issue. > > > > Translate exists because it solves this problem by identifying GETs > > >from DAV clients. If we have to use Translate to give our customers > > what they want, then so be it. I was just hoping we could get > > something defined by a group of thoughtful people instead of > > something undocumented. > > > > > > cjh > > > > -- > > > > From w3c-dist-auth-request@w3.org Mon Mar 4 17: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 RAA27217 for ; Mon, 4 Mar 2002 17:18:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA03319; Mon, 4 Mar 2002 17:14:27 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 17:14:27 -0500 (EST) Resent-Message-Id: <200203042214.RAA03319@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 RAA03287 for ; Mon, 4 Mar 2002 17:14:08 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA31574 for ; Mon, 4 Mar 2002 17:14:08 -0500 Received: from 10.196.0.11 by mail.4d.com; Mon, 4 Mar 2002 14:14:09 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: Date: Mon, 4 Mar 2002 14:11:02 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6020 X-Loop: w3c-dist-auth@w3.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 source property is the only mechanism I know of that truly allows the >Web interface to be used for authoring of the source resources of >dynamically generated content. Agreed. But this is irrelevant to most users. >Quite frankly, if a person cannot implement that in a trivial amount of time >then I'd like to know how their Web server manages to generate the dynamic >content in the first place. If it is so trivial, why isn't it implemented? It's not because the programmers are simply lazy. Look at all the stuff the *is* implemented wrt DAV. Even fairly hard stuff like locks and storing arbitrary properties is implemented. But this one trivial thing is not. The *concept* is simple, yet it remains unimplemented after three years. As long as people keep insisting that it is simple, I'm going to keep pointing that out. I'm thinking now that I like the DAV-Enabled field idea better than GETSRC, since it doesn't mess with the data model. But I realize the same people will protest it for the same reasons. cjh -- From w3c-dist-auth-request@w3.org Mon Mar 4 17:18: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 RAA27230 for ; Mon, 4 Mar 2002 17:18:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA03351; Mon, 4 Mar 2002 17:14:41 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 17:14:41 -0500 (EST) Resent-Message-Id: <200203042214.RAA03351@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 RAA03289 for ; Mon, 4 Mar 2002 17:14:08 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA31575 for ; Mon, 4 Mar 2002 17:14:08 -0500 Received: from 10.196.0.11 by mail.4d.com; Mon, 4 Mar 2002 14:14:08 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: Date: Mon, 4 Mar 2002 14:10:36 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6021 X-Loop: w3c-dist-auth@w3.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 most fundamental question from a data modeling perspective >is the following: "Is the source the same entity as its output?" >Julian and I agree that it is not. RFC2616 section 9.3 says >it is not. Julian has provided examples below, including the >case of multiple outputs from the same source supporting that >position. I've given in on the source-vs-display URI. In fact, I've always acknowledged that it is a perfectly good model. What I'm trying to do is allow people who only use DAV for editing sources to not have to do extra configurations to make it happen. All I'm asking for at this point is some way for server implementors to know when a GET arrives from a DAV client. A DAV-Enabled (or whatever) field on the requests would do that. I'm not trying to break the model, or add new methods. I just want to know when a DAV client is GETting a resource vs a normal web client. Why? Because what most users expect is to be able to edit their pages at the same URI. I realize that doesn't fit your model, but it is what most people really want from DAV. Even assuming we were to implement a way for our DAV to map sources onto some user-configurable alternate URI space with a minimal amount of configuration, one of the first things people would ask us is why they can't use the same URIs for DAV and for their web browser. And they aren't going to understand the data modeling argument. I think having this field would: (a) speed up the adoption of DAV by solving a serious problem (b) retain the clarity of the data model and make it clear that a good implementation would have separate URI spaces (c) ultimately encourage use of DAV:source, since lots of people will finally be using DAV and start to understand the advantages of source vs display URIs I realize adding such a field would not contribute materially to the data model or the theoretical soundness of the protocol, but it would remove a major headache from the configuration and management from most DAV servers. cjh -- From w3c-dist-auth-request@w3.org Mon Mar 4 17:32: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 RAA28035 for ; Mon, 4 Mar 2002 17:32:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA05112; Mon, 4 Mar 2002 17:28:31 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 17:28:31 -0500 (EST) Resent-Message-Id: <200203042228.RAA05112@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 RAA05087 for ; Mon, 4 Mar 2002 17:28: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 RAA01457 for ; Mon, 4 Mar 2002 17:28:22 -0500 Received: (qmail 19884 invoked by uid 0); 4 Mar 2002 22:27:43 -0000 Received: from pd9535458.dip.t-dialin.net (HELO lisa) (217.83.84.88) by mail.gmx.net (mp009-rz3) with SMTP; 4 Mar 2002 22:27:43 -0000 From: "Julian Reschke" To: "Eric Sedlar" , Date: Mon, 4 Mar 2002 23:27:34 +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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6022 X-Loop: w3c-dist-auth@w3.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, thanks for taking the time to write this long reply. I am putting some comments inline... > From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com] > Sent: Monday, March 04, 2002 8:48 PM > To: Julian Reschke; CJ Holmes; w3c-dist-auth@w3.org > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > It's not clear to me that the generated output from GET on executables > actually is a different resource. First of all, it doesn't make sense to > think of it as having properties separate from that of the > script. I doubt It does. For instance, DAV:getcontenttype will almost certainly have a different value, so will DAV:getcontentlength. > if anyone actually doing the URL space mapping proposed would > keep around a > set of dead properties for the generated output, but the case becomes > clearer when looking at the live properties. Well, I wouldn't expect a server to store dead properties for a "output" resource, but this is really an implementation detail. > If I have a directory full of .ASPs, or .JSP files, and I do a PROPFIND on > that directory, will the server actually execute all of the scripts in the > directory in order, dumping their output to a temp file, to ensure that > dav:getcontentlength is correct? I bet nobody actually does that A conforming server will either report these properties as empty or as non-existant (unless it's actually able to compute these values cheaply). > (it would > be "considered harmful" like PROPFIND depth infinity), and if you did it > would be stupid. I haven't checked this, but I bet that most > servers return > the length of the underlying script as the length of the > generated output on IMHO this would be a bug. > a PROPFIND depth 1. The same difficulties apply to and many > other live properties. The reason this doesn't matter in practice is that > returning the wrong etag or wrong content length for generated output is > irrelevant, since in the general case it cannot be cached, and it works Why do you say that generated output can not be cached? A big part of the HTTP spec treats this very problem. > functionally just as if the resource was changed before the > subsequent GET, > so it's ok if the value of is different in a > PROPFIND on > its parent and the actual content length returned when you do a GET. > > I think that the better model is if you think of the GET method more like > the "OPEN" action on Windows or Macintosh, which means to execute > this file > if executable, or else display the contents of the document. GET > is really > like a simple case of the POST method (which was originally how it was > conceived). To illustrate this point, let's say that a particular server > said that POST on a non-executable resource (like a static file) > would dump > its contents (like a GET). Now we can clearly see GET on a script as a > simple case of POST. GET doesn't dump "the content" of a resource. GET returns an entity which is one of many possible representations of the resource, which may depend on non-URL based information in the headers (in which case these headers should be listed in the "Vary" header). > Julian's argument below gets at the heart of the problem--is each set of > possible output generated by a script a different resource? First of all, > there are many different things that can affect the output of a resource, > and most of them are not in the URL (which is the only thing that can be > used to differentiate two resources). While the URL arguments in > the query > string are one set of arguments to the script, clearly information in the > header may also be used (even in a GET method). For example, the Yes. > authentication headers may be used to choose whose shopping cart will be > displayed, or in POST, the form values appear in headers. If, as Julian > suggests: GET /foo/my.jsp?arg1=val1 is a different resource than GET > /foo/my.jsp?arg1=val2, then POST /foo/my.jsp with a header Arg1: GET ... is not a resource, it's one representation of a resource. URLs (as they are URIs as defined in RFC2396) identify resources. If they differ, this is a good indication that the resource they identify differs as well. > val1 should > be different than POST /foo/my.jsp with header Arg1: val2. This obviously > makes no sense. I don't understand the analogy to POST. POST is very different from GET in it's semantics (it's not just a distinction in marshalling). > So, here are my arguments for why each possible output generated > by a script > should not be a separate resource: I didn't say that. What I'm saying is that the set of outputs (that can be generated by a GET on a URL) is a different resource than the source resource. > * they may not have separate URLs, since not all of the arguments > that cause > different output may be in the URL string--they may be in headers, or may > depend on other server state That's fine. So all of them are the same abstract resource. > * it is impractical to manage dead properties for each possible output That's no problem. If you don't want to, don't. > * it is computationally difficult to return dead properties (such as > dav:getcontentlength) for each possible output Again fine. Don't return them. > Therefore, I conclude that generated output is not a resource, and You can't conclude that, because the generated output *has* a URL, so it *must* be a representation of an abstract resource. > especially not a dav-enabled resource. I would recommend that server > implementers NOT return script output as dav enabled. That's fine. You don't have to. > Now, on to the practical argument, which will demonstrate that > dav:source is > a lot less usable than GETSRC/Translate: > > let's say that I have a directory full of scripts and static > files. I want > to manage them from a authoring point of view. If I want to implement > dav:source, I need to create some virtual URL space that > corresponds to the > physical URL space where the actual script source is stored. I Actually, I'd say that you should create mappings for the outputs, not for the sources, but this is just a matter of taste, I guess. > can make the > virtual URL space return either the generated output, or the source, at > least from an implementation point of view. For example: > > Contents of /mydir: > > foo.jsp > bar.html > bar.gif > > In case 1, let's say I make /scripts/src/ a virtual URL space > that returns the source of any executables (for DAV clients), so where GET > /mydir/foo.jsp will return the generated output, > /scripts/src/mydir/foo.jsp > will return the source. dav:source on /mydir/foo.jsp will point to > /scripts/src/mydir/foo.jsp. The DAV client doesn't actually want to mess > with /mydir/foo.jsp since it is generated, has bogus live property values, > doesn't respond to things like PUT, and is generally not very > helpful. Now > I'm forced into a separate tree, which is certainly annoying from a That's something the client should do for you. > useability point of view, and extremely annoying when doing things like > copying with Web Folders, since when I drag & drop my app from the local > filesystem to the server, my .jsp files move to another place, and when I > copy the application back down to my local PC, the .jsps were > moved (even if > I was smart enough to realize where they magically went to). So, > this is a > bad solution. Why don't you just edit *all* files in the source directory and leave the output resources alone? > In case 2, let's say I make /script/output/ a virtual URL space > that returns the generated output for the executables. Now the DAV client > is happy, since the server space looks like the space on the client. > Unfortunately, all of the tags in any HTML output are > screwed up vs. > the local copy (e.g if bar.html wanted a link to foo.jsp, or vice versa), > since neither a relative nor an absolute URL will work, and the > URLs needed > are server implementation-dependent. > > The reality of the world is that people want to be able to move their > content creation environment back and forth between local filesystems and > DAV servers. Any usage of dav:source would break that abstraction, since > local filesystems aren't capable of implementing virtual URL spaces. I Again, that's not true. You can author the *source* URL space just like always. All you need the DAV:source property for is to discover where those files sit. > think these are the practical reasons why nobody has implemented > dav:source > in the past 3 years. The DAV:source property is underspecified in the spec, that's the reason it's not implemented. That doesn't make the concept itself bad. > So, it is clear that: > > * generated output (from stuff like .jsps, .asps, cgi) does not make sense > as a DAV-enabled resource, since the only methods it is likely to > respond to > intelligently is GET. I don't have any problem with this. If output resources aren't WEBDAV enabled, you just lose the ability to use DAV:source to discover their sources. > * separating the URL space of generated output and source causes usability > problems, making life awkward either for the DAV client, or for the HTML > linking I don't agree. > I think the argument for a GETSRC method becomes clear if you mentally > rename GET to LIMITED-VERSION-OF-POST. GET and POST are fundamentelly different things. > Reponses to a couple of other points in more recent emails: > > Alan Babich says: > > "Is the source the same entity as its output?" Julian and I agree > that it is > not. RFC2616 section 9.3 says it is not. > > Response: the issue is not whether or not the source and the output are > the same "entity", but the same DAV resource. Entity and resource are ...the same HTTP resource... > different things. There are three general categories of things that can Yes. > cause the output of a generated script to vary: URL information, e.g. the > query string; header information; or server-state (like in a database). > Clearly the URL isn't sufficient to differentiate between all the kinds of > server-generated output, so the various entities that can be > generated by a > script cannot be mapped as separate resources, since they won't have > separate URLs. If they don't have separate URLs, they aren't different abstract resources. In the case of the shopping cart mentioned earlier, the resource identified by the URL is "the shopping cart of the currently logged in user". It's no problem if it's different for different users. > Roy Fielding says: > > Any server that allows clients to vary GET responses based on the > Translate > header field MUST include "Vary: Translate" in every response to the GET > method in order to remain compliant with HTTP/1.1. > > Response: Actually, RFC2616 says: "An HTTP/1.1 server SHOULD include a > Vary header field with any cacheable response that is subject to > server-driven negotiation." So, clearly, Microsoft is in compliance with > the HTTP specification since this is not a MUST requirement. SHOULD (as defined in RFC2119): "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." To still claim conformance, one would have to specify these valid reasons. Can you think of any? > Clearly it is > acceptable to use header values to vary the content of generated state, Yes, but by doing to you state that all entities that you return are representations of the same resource. Are they? > whether it be the Translate header or the Authentication header, > and whether > or not the Vary header is supplied is a completely orthogonal issue. Yes. But you SHOULD indicate it in the "Vary" header. > Here's another way to look at the categorization of response entities for > executables: > > 1) the source > 2) generated output that does not vary based on input arguments > from client > 3) generated output varying with input arguments from client encoded in > query string > 4) generated output varying with input arguments from client encoded in > request headers > 5) generated output varying with server-side state (like information in a > database) > > I don't see why case #2 and case #3 (in Julian's example) should > be awarded > its own status as a "real dav resource" when cases #4 and #5 are not. Because resources are *identified* by their URLs. If the URL is the same, it's *by definition* the same resource. > I'd like to see someone propose a scheme for implementing dav:source that > solves the usability problem when mapping to the local filesystem, if they > believe in dav:source. First of all, I strongly object to this line of argument. Even *if* you can demonstrate that DAV:source as it is doesn't work, this doesn't mean that this makes the Translate header an acceptable solution. This having said, I don't see any problem having two separate URL spaces, and to only author the source space. The output space *may* be DAV enabled, and if it is, it should use DAV:source or something similar we'll come up with to indicate where the source is. Julian From w3c-dist-auth-request@w3.org Mon Mar 4 17:35: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 RAA28208 for ; Mon, 4 Mar 2002 17:35:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA05283; Mon, 4 Mar 2002 17:30:46 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 17:30:46 -0500 (EST) Resent-Message-Id: <200203042230.RAA05283@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 RAA05224 for ; Mon, 4 Mar 2002 17:30:38 -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 RAA01736 for ; Mon, 4 Mar 2002 17:30:37 -0500 Received: (qmail 27749 invoked by uid 0); 4 Mar 2002 22:30:01 -0000 Received: from pd9535458.dip.t-dialin.net (HELO lisa) (217.83.84.88) by mail.gmx.net (mp006-rz3) with SMTP; 4 Mar 2002 22:30:01 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Mon, 4 Mar 2002 23:29:53 +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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6023 X-Loop: w3c-dist-auth@w3.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: Monday, March 04, 2002 11:11 PM > To: DAV > Subject: Re: A case for GETSRC (or other mechanism to that effect) > > > >The source property is the only mechanism I know of that truly allows the > >Web interface to be used for authoring of the source resources of > >dynamically generated content. > > Agreed. But this is irrelevant to most users. > > >Quite frankly, if a person cannot implement that in a trivial > amount of time > >then I'd like to know how their Web server manages to generate > the dynamic > >content in the first place. > > If it is so trivial, why isn't it implemented? It's not because the > programmers are simply lazy. Look at all the stuff the *is* > implemented wrt DAV. Even fairly hard stuff like locks and storing > arbitrary properties is implemented. But this one trivial thing is > not. The *concept* is simple, yet it remains unimplemented after > three years. Because it's underspecified. There's even an entry related to this on the RFC2518 open issues list. > As long as people keep insisting that it is simple, I'm going to keep > pointing that out. So will I if this fact continues to be ignored. From w3c-dist-auth-request@w3.org Mon Mar 4 17:38: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 RAA28400 for ; Mon, 4 Mar 2002 17:38:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA05649; Mon, 4 Mar 2002 17:34:14 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 17:34:14 -0500 (EST) Resent-Message-Id: <200203042234.RAA05649@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 RAA05541 for ; Mon, 4 Mar 2002 17:33:57 -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 RAA02291 for ; Mon, 4 Mar 2002 17:33:56 -0500 Received: (qmail 14213 invoked by uid 0); 4 Mar 2002 22:33:22 -0000 Received: from pd9535458.dip.t-dialin.net (HELO lisa) (217.83.84.88) by mail.gmx.net (mp004-rz3) with SMTP; 4 Mar 2002 22:33:22 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Mon, 4 Mar 2002 23:33:16 +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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6024 X-Loop: w3c-dist-auth@w3.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: Monday, March 04, 2002 11:11 PM > To: DAV > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > >The most fundamental question from a data modeling perspective > >is the following: "Is the source the same entity as its output?" > >Julian and I agree that it is not. RFC2616 section 9.3 says > >it is not. Julian has provided examples below, including the > >case of multiple outputs from the same source supporting that > >position. > > I've given in on the source-vs-display URI. In fact, I've always > acknowledged that it is a perfectly good model. What I'm trying to > do is allow people who only use DAV for editing sources to not have > to do extra configurations to make it happen. > > All I'm asking for at this point is some way for server implementors > to know when a GET arrives from a DAV client. A DAV-Enabled (or > whatever) field on the requests would do that. I'm not trying to > break the model, or add new methods. I just want to know when a DAV > client is GETting a resource vs a normal web client. This *is* the problem. GET is GET. It's an HTTP method. Once you are making it depend on the type of client, you *are* breaking the HTTP model. > Why? Because what most users expect is to be able to edit their > pages at the same URI. I realize that doesn't fit your model, but it > is what most people really want from DAV. People want to send around URL that point to output resources. They *also* want to send around URLs that point to source resources. This isn't possible if the URLs are the same. Now what? > Even assuming we were to implement a way for our DAV to map sources > onto some user-configurable alternate URI space with a minimal amount > of configuration, one of the first things people would ask us is why > they can't use the same URIs for DAV and for their web browser. And > they aren't going to understand the data modeling argument. But maybe they would be able to understand my previous argument? > I think having this field would: > > (a) speed up the adoption of DAV by solving a serious problem > > (b) retain the clarity of the data model and make it clear > that a good implementation would have separate URI spaces > > (c) ultimately encourage use of DAV:source, since lots of > people will finally be using DAV and start to understand the > advantages of source vs display URIs > > > I realize adding such a field would not contribute materially to the > data model or the theoretical soundness of the protocol, but it would > remove a major headache from the configuration and management from > most DAV servers. I disagree. Your proposal breaks GET in a very fundamental way. From w3c-dist-auth-request@w3.org Mon Mar 4 17:54: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 RAA28850 for ; Mon, 4 Mar 2002 17:54:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA07631; Mon, 4 Mar 2002 17:49:28 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 17:49:28 -0500 (EST) Resent-Message-Id: <200203042249.RAA07631@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 RAA07580 for ; Mon, 4 Mar 2002 17:49:06 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA05628 for ; Mon, 4 Mar 2002 17:49:06 -0500 Received: from 10.196.0.11 by mail.4d.com; Mon, 4 Mar 2002 14:49:06 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 4 Mar 2002 14:44:44 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6025 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: >GET doesn't dump "the content" of a resource. GET returns an entity which is >one of many possible representations of the resource, which may depend on >non-URL based information in the headers (in which case these headers should >be listed in the "Vary" header). You mean like a "DAV-Enabled" header field? In which case "DAV-Enabled" would appear in the Vary field of the response? A "resource" is a rather malleable concept, and as you've stated here there may be many representations of that resource. I don't see that it would be so horrible to allow the idea that one of the representations of a resource could be its raw source. What representation you receive is a matter of server policy. And some way of identifying that the server is talking to a DAV client would help with managing that policy. cjh -- From w3c-dist-auth-request@w3.org Mon Mar 4 18:04: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 SAA29227 for ; Mon, 4 Mar 2002 18:04:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08237; Mon, 4 Mar 2002 17:59:46 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 17:59:46 -0500 (EST) Resent-Message-Id: <200203042259.RAA08237@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 RAA08198 for ; Mon, 4 Mar 2002 17:59:20 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA07136 for ; Mon, 4 Mar 2002 17:59:20 -0500 Received: from 10.196.0.11 by mail.4d.com; Mon, 4 Mar 2002 14:59:20 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 4 Mar 2002 14:57:31 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6026 X-Loop: w3c-dist-auth@w3.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 I'm asking for at this point is some way for server implementors >> to know when a GET arrives from a DAV client. A DAV-Enabled (or >> whatever) field on the requests would do that. I'm not trying to >> break the model, or add new methods. I just want to know when a DAV >> client is GETting a resource vs a normal web client. > >This *is* the problem. GET is GET. It's an HTTP method. Once you are making >it depend on the type of client, you *are* breaking the HTTP model. GET returns different things for all kinds of different reasons. The time of day, the browser in use, the phase of the moon, authentication credentials, your IP address, how much coffee is left in the coffee machine, etc.. The body that is returned from GET is a policy matter that is determined by the administrator, not by this list. > > Why? Because what most users expect is to be able to edit their >> pages at the same URI. I realize that doesn't fit your model, but it >> is what most people really want from DAV. > >People want to send around URL that point to output resources. They *also* >want to send around URLs that point to source resources. This isn't possible >if the URLs are the same. Again, not your problem. If someone *wants* to have a special URI space for DAV access, then they are welcome to configure their server's policy accordingly. > > Even assuming we were to implement a way for our DAV to map sources > > onto some user-configurable alternate URI space with a minimal amount > > of configuration, one of the first things people would ask us is why > > they can't use the same URIs for DAV and for their web browser. And > > they aren't going to understand the data modeling argument. > >But maybe they would be able to understand my previous argument? Eventually. But they would rather the thing "just work". Latter on they'll read the manual, figure out other configurations, and decide if they want to change how they're doing things. >I disagree. Your proposal breaks GET in a very fundamental way. Nah... It is still GET. I'm just asking for the input I need for policy decisions. The bandwidth is minimal, the processing time required is about nil, what's not to like? cjh -- From w3c-dist-auth-request@w3.org Mon Mar 4 18:08: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 SAA29315 for ; Mon, 4 Mar 2002 18:08:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA08775; Mon, 4 Mar 2002 18:04:24 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 18:04:24 -0500 (EST) Resent-Message-Id: <200203042304.SAA08775@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 SAA08755 for ; Mon, 4 Mar 2002 18:04:16 -0500 (EST) Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA08520 for ; Mon, 4 Mar 2002 18:04:16 -0500 Received: from manyfish.co.uk ([213.107.107.219]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020304230415.LEWA7206.mta05-svc.ntlworld.com@manyfish.co.uk> for ; Mon, 4 Mar 2002 23:04:15 +0000 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g24N3lW06985 for w3c-dist-auth@w3.org; Mon, 4 Mar 2002 23:03:47 GMT Date: Mon, 4 Mar 2002 23:03:47 +0000 From: Joe Orton To: DAV Message-ID: <20020304230347.A6970@light.plus.com> Mail-Followup-To: DAV References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from cholmes@4d.com on Mon, Mar 04, 2002 at 02:11:02PM -0800 Subject: Re: A case for GETSRC (or other mechanism to that effect) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6027 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Mar 04, 2002 at 02:11:02PM -0800, CJ Holmes wrote: > >Quite frankly, if a person cannot implement that in a trivial amount of time > >then I'd like to know how their Web server manages to generate the dynamic > >content in the first place. > > If it is so trivial, why isn't it implemented? It's not because the > programmers are simply lazy. Look at all the stuff the *is* > implemented wrt DAV. Even fairly hard stuff like locks and storing > arbitrary properties is implemented. But this one trivial thing is > not. The *concept* is simple, yet it remains unimplemented after > three years. At least with mod_dav users, I think it's not been implemented yet because you don't *need* the source property to be able to author dynamic resources, since you can say to your users "use URL 'A' for authoring and URL 'B' for browsing". People may be used to that anyway: "use this ftp:// URL for authoring, and this http:// one browsing". Zope's DAV support does (or did) include support for the source property, although, according to this thread, not in a useful form: http://mailman.lyra.org/pipermail/cadaver/2001-September/000231.html joe From w3c-dist-auth-request@w3.org Mon Mar 4 18:20:11 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 SAA29556 for ; Mon, 4 Mar 2002 18:20:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA09863; Mon, 4 Mar 2002 18:16:02 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 18:16:02 -0500 (EST) Resent-Message-Id: <200203042316.SAA09863@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 SAA09822 for ; Mon, 4 Mar 2002 18:15:38 -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 SAA09964 for ; Mon, 4 Mar 2002 18:15:38 -0500 Received: (qmail 6965 invoked by uid 0); 4 Mar 2002 23:15:06 -0000 Received: from pd9535458.dip.t-dialin.net (HELO lisa) (217.83.84.88) by mail.gmx.net (mp015-rz3) with SMTP; 4 Mar 2002 23:15:06 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Tue, 5 Mar 2002 00:15:01 +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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6028 X-Loop: w3c-dist-auth@w3.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: Monday, March 04, 2002 11:45 PM > To: DAV > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > >GET doesn't dump "the content" of a resource. GET returns an > entity which is > >one of many possible representations of the resource, which may depend on > >non-URL based information in the headers (in which case these > headers should > >be listed in the "Vary" header). > > You mean like a "DAV-Enabled" header field? In which case > "DAV-Enabled" would appear in the Vary field of the response? CJ, first of all: What is the *meaning* of "DAV-Enabled"? As you are proposing this header, you should define what it means. Is an HTML editor that uses PROPFIND/GET/PUT/LOCK to author HTML files "DAV-Enabled"? If yes, what do you do if it has a test function that needs to access the output resource rather than the source resource? I think "Translate" is much clearer than "DAV-Enabled" because it at least it says what you want. And yes, if you *do* take the position that the source and it's output are different representations of the same resource, then the "Translate" header *does* make sense (and you should list in in the "Vary" header when responsing). As I've said numerous times: make up your mind whether the source and it's output are the same resource or not. If they are, you can use "Translate". If they aren't, they will have different URLs. HTTP takes the position that they are different resources (see introduction to "GET"), and I don't see how a different working group could change this view. > A "resource" is a rather malleable concept, and as you've stated here > there may be many representations of that resource. I don't see that > it would be so horrible to allow the idea that one of the > representations of a resource could be its raw source. What The most horrible thing being that the source resource doesn't have it's own URL and thus cannot be properly referred to using just a URL. Could you please explain why you think this particular problem *isn't* relevant? > representation you receive is a matter of server policy. And some > way of identifying that the server is talking to a DAV client would > help with managing that policy. No, "DAV-Enabled" vs. "Translate" is the completely wrong approach. Following your proposal, a "DAV enabled" client never would want to GET the output resource. This is obviously a wrong assumption. From w3c-dist-auth-request@w3.org Mon Mar 4 18:30: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 SAA29834 for ; Mon, 4 Mar 2002 18:30:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA11586; Mon, 4 Mar 2002 18:25:07 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 18:25:07 -0500 (EST) Resent-Message-Id: <200203042325.SAA11586@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 SAA11564 for ; Mon, 4 Mar 2002 18:24:47 -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 SAA11405 for ; Mon, 4 Mar 2002 18:24:47 -0500 Received: (qmail 8673 invoked by uid 0); 4 Mar 2002 23:24:13 -0000 Received: from pd9535458.dip.t-dialin.net (HELO lisa) (217.83.84.88) by mail.gmx.net (mp010-rz3) with SMTP; 4 Mar 2002 23:24:13 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Tue, 5 Mar 2002 00:24: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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6029 X-Loop: w3c-dist-auth@w3.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: Monday, March 04, 2002 11:58 PM > To: DAV > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > > > All I'm asking for at this point is some way for server implementors > >> to know when a GET arrives from a DAV client. A DAV-Enabled (or > >> whatever) field on the requests would do that. I'm not trying to > >> break the model, or add new methods. I just want to know when a DAV > >> client is GETting a resource vs a normal web client. > > > >This *is* the problem. GET is GET. It's an HTTP method. Once you > are making > >it depend on the type of client, you *are* breaking the HTTP model. > > GET returns different things for all kinds of different reasons. The > time of day, the browser in use, the phase of the moon, > authentication credentials, your IP address, how much coffee is left > in the coffee machine, etc.. Yes, but all of these *by definition* still are representations of the same resource. You can't argue with this, this is how it is defined. > The body that is returned from GET is a policy matter that is > determined by the administrator, not by this list. Yes, but if you allow the same URL both to respond with it's source and generated output, it will be hard to define what this resource *is* (give a definition!). You can't say anymore: "it's a representation of the current user's shopping cart". > > > Why? Because what most users expect is to be able to edit their > >> pages at the same URI. I realize that doesn't fit your model, but it > >> is what most people really want from DAV. > > > >People want to send around URL that point to output resources. > They *also* > >want to send around URLs that point to source resources. This > isn't possible > >if the URLs are the same. > > Again, not your problem. If someone *wants* to have a special URI > space for DAV access, then they are welcome to configure their > server's policy accordingly. If they do, they can use DAV:source. Great. Problem solved. No need for a new protocol which (in my opinion) breaks HTTP. > > > Even assuming we were to implement a way for our DAV to map sources > > > onto some user-configurable alternate URI space with a minimal amount > > > of configuration, one of the first things people would ask us is why > > > they can't use the same URIs for DAV and for their web browser. And > > > they aren't going to understand the data modeling argument. > > > >But maybe they would be able to understand my previous argument? > > Eventually. But they would rather the thing "just work". Latter on > they'll read the manual, figure out other configurations, and decide > if they want to change how they're doing things. So you're proposing to change the basic definition of GET because you feel it's harder to explain the proper solution to your users? That's really a weak argument. > >I disagree. Your proposal breaks GET in a very fundamental way. > > Nah... It is still GET. I'm just asking for the input I need for > policy decisions. The bandwidth is minimal, the processing time > required is about nil, what's not to like? GET is GET. It shouldn't depend on whether a client happens to know that WebDAV exists. Just because a user agent knows about PROPFIND doesn't mean that it never will want to GET the output resource. And a user agent that happens *not* to know about WebDAV still should be able to get the source. WebDAV doesn't replace HTTP, it *extends* HTTP. HTTP defines how GET is working, not WebDAV. From w3c-dist-auth-request@w3.org Tue Mar 5 01:23: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 BAA10565 for ; Tue, 5 Mar 2002 01:23:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA26838; Tue, 5 Mar 2002 01:12:22 -0500 (EST) Resent-Date: Tue, 5 Mar 2002 01:12:22 -0500 (EST) Resent-Message-Id: <200203050612.BAA26838@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 BAA26808 for ; Tue, 5 Mar 2002 01:11:57 -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 BAA24096 for ; Tue, 5 Mar 2002 01:11:57 -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 BAA324064; Tue, 5 Mar 2002 01:08: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/VER6.00) with ESMTP id g256BM996058; Tue, 5 Mar 2002 01:11:22 -0500 To: "Eric Sedlar" Cc: "CJ Holmes" , "Julian Reschke" , w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Mon, 4 Mar 2002 23:59:16 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 03/05/2002 01:11:22 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6032 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Eric, Nice post. > It's not clear to me that the generated output from GET on executables > actually is a different resource. First of all, it doesn't make sense to > think of it as having properties separate from that of the script. I doubt > if anyone actually doing the URL space mapping proposed would keep around a > set of dead properties for the generated output, but the case becomes > clearer when looking at the live properties. I think you're right that a lot of those properties have limited value for a dynamic resource. Sometimes they are hard to implement efficiently. Sometimes the correct value for the server to return for a property might be ambiguous. OTOH... for the underlying source resource, these properties are probably useful, very clearly defined and easy for the server to return. That seems to be a good reason to keep the source resource seperate from the complexity and ambiguity of the dynamic resource. This is just a response to the first part of your note. It doesn't respond to the second part of your note about MOVE which requires more thought. Again... thanks for your thoughtful note. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Tue Mar 5 10: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 KAA03940 for ; Tue, 5 Mar 2002 10:14:26 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA19110; Tue, 5 Mar 2002 10:08:25 -0500 (EST) Resent-Date: Tue, 5 Mar 2002 10:08:25 -0500 (EST) Resent-Message-Id: <200203051508.KAA19110@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 KAA18959 for ; Tue, 5 Mar 2002 10:07:41 -0500 (EST) Received: from web11006.mail.yahoo.com (web11006.mail.yahoo.com [216.136.131.56]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA16396 for ; Tue, 5 Mar 2002 10:07:41 -0500 Message-ID: <20020305150740.58526.qmail@web11006.mail.yahoo.com> Received: from [80.252.161.6] by web11006.mail.yahoo.com via HTTP; Tue, 05 Mar 2002 07:07:40 PST Date: Tue, 5 Mar 2002 07:07:40 -0800 (PST) From: akhil gupta To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6033 X-Loop: w3c-dist-auth@w3.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 Can you please tell me how using the webdav we can save files on internet, means i want to write a program for opening a file through a site of the format of MS Word or Excel, edit it and save it back on the remote computer, from where it was opened. Please tell me urgently how to do it, using webdav or else. Thanks Akhil Gupta __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From w3c-dist-auth-request@w3.org Tue Mar 5 13:04: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 NAA12986 for ; Tue, 5 Mar 2002 13:04:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08295; Tue, 5 Mar 2002 12:59:50 -0500 (EST) Resent-Date: Tue, 5 Mar 2002 12:59:50 -0500 (EST) Resent-Message-Id: <200203051759.MAA08295@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 MAA08219 for ; Tue, 5 Mar 2002 12:59:17 -0500 (EST) Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01929 for ; Tue, 5 Mar 2002 12:59:16 -0500 Received: from dialup-209.247.244.68.dial1.sanfrancisco1.level3.net ([209.247.244.68] helo=[10.0.1.20]) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iJDW-00013N-00 for w3c-dist-auth@w3.org; Tue, 05 Mar 2002 09:59:15 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 5 Mar 2002 10:04:21 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6034 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: ><< > (2) "Once the software is written, the dual-URI space is both >superior and cost-free." It is confusing to users when they >configure their DAV client software, and providing support is >expensive. >>> >I don't think anyone went so far as to say it's "cost-free". Ok, I exaggerated. But I think the point is still a good one. Even if the implementation is cheap, support can still be very expensive. Hence the need for a single URI space from the user's point of view. ><< >Put yourself in the shoes of the administrator of a University's >faculty web pages server trying to provide DAV access to their pages. >Let's say there are about 1200 faculty at your school, and only 1/4 >of them have web pages but only update them a couple times a year. >That's about 300 phone calls and emails you are going to get twice a >year asking why they can't get the SSI version of the such-and-such >page or why they can't "log in with Dreamweaver" to their web page. >(Reminder: these people are too "smart" to RTFM.) > >With this crowd, it would be way easier to just serve the source to >DAV clients (subject to the proper authentication of course) and >avoid a lot of these support incidents. None of them care about >using DAV on display documents at all. >>> >Right... it's probably no worse than the current situation with FTP, >but if you can improve on the current situation , it can create new >opportunities. In this case it would save money for the support >staff at the university. Right. Only DAV is already much better than FTP even without DAV:source. You have arbitrary properties (which many users find useful over time) and Locking. I'm a big fan of locks. >People have pointed out that the mapping from display URI to >source URI can be any number of functions. This has been >viewed as a feature because it allows the server implementer >to use whatever mapping makes most sense to him. But that flexibility >causes complications for a UI that wants to simulate a single URI >space. Not just complications in the UI, but also complications for the server administrator and for plug-ins trying to stay out of each others' way, and configuring security realms that are DAV-specific and largely duplications/variations of permissions elsewhere in the URI space. A lot of our customers are beginning web masters. They want a product the works easily "out-of-the-box" and is easy to support. They also want something that will grow with them. Hence our desire to provide a simple default configuration (DAV-as-file-system with no funny business with the URI space) AND the opportunities for a "real" configuration that uses DAV:source and maps two spaces together, etc.. >The client UI doesn't know enough to easily figure out what >the mapping function is so it can have trouble supporting a MOVE >operation that looks like a MOVE in a single URI space. (At >least that's my current understanding. I haven't >thought about Eric's posting long enough to be sure.) I think it can just ask about the source URI of the destination (unless that destination doesn't exist - then what?) >I'm wondering now if the DAV:source property definition can be >constrained so that a client can trivially know how the two >namespaces map to each other so that it can know how to do a >MOVE in the output URI space and simulate a single URI space. That's an interesting idea. cjh -- From w3c-dist-auth-request@w3.org Tue Mar 5 17:19: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 RAA02907 for ; Tue, 5 Mar 2002 17:19:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06266; Tue, 5 Mar 2002 17:15:16 -0500 (EST) Resent-Date: Tue, 5 Mar 2002 17:15:16 -0500 (EST) Resent-Message-Id: <200203052215.RAA06266@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 RAA06243 for ; Tue, 5 Mar 2002 17:14:50 -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 RAA23338 for ; Tue, 5 Mar 2002 17:14:50 -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 OAA02756; Tue, 5 Mar 2002 14:14:53 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Cc: Date: Tue, 5 Mar 2002 14:15: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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: Newbie Question on WebDAV/Tomcat Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6035 X-Loop: w3c-dist-auth@w3.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: jreid@dpt-ltd.co.uk [mailto:jreid@dpt-ltd.co.uk] Sent: Tuesday, March 05, 2002 6:41 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Newbie Question on WebDAV/Tomcat Sorry for posting this here but I don't know of anyone else who can help me. I've recently downloaded and installed Tomcat version 4.0.1 onto my Linux webserver running Apache. The setup was successful and I can view the Tomcat page at http://www.dpt-ltd.co.uk:8888/index.html I noticed that the page contained information on WebDAV, which interested me greatly as being able to remotely author my website would make my life a whole lot easier. However I can't get it to work! I've modified the web.xml file under /var/tomcat4/webapps/webdav/WEB-INF to allow read/write access and then restarted Tomcat. I then go to File -> Open in IE6 and try to open http://www.dpt-ltd.co.uk:8888/webdav as a Web Folder, but get the following error message... Internet Explorer could not open http://www.dpt-ltd.co.uk:8888/webdav as a Web Folder. Would you like to see its default view instead? Can anyone see what I'm doing wrong? It all seems fairly straightforward but I simply can't get it to work. :( Please reply to me off-list if possible. Thanks in advance, James From w3c-dist-auth-request@w3.org Tue Mar 5 17:20: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 RAA02940 for ; Tue, 5 Mar 2002 17:20:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06427; Tue, 5 Mar 2002 17:16:23 -0500 (EST) Resent-Date: Tue, 5 Mar 2002 17:16:23 -0500 (EST) Resent-Message-Id: <200203052216.RAA06427@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 RAA06395 for ; Tue, 5 Mar 2002 17:15:59 -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 RAA23463 for ; Tue, 5 Mar 2002 17:15:59 -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 OAA03318 for ; Tue, 5 Mar 2002 14:16:02 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 5 Mar 2002 14:16:14 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Using DAV to save files Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6036 X-Loop: w3c-dist-auth@w3.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. - Jim -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of akhil gupta Sent: Tuesday, March 05, 2002 7:08 AM To: w3c-dist-auth@w3.org Subject: [w3c-dist-auth] Hi Can you please tell me how using the webdav we can save files on internet, means i want to write a program for opening a file through a site of the format of MS Word or Excel, edit it and save it back on the remote computer, from where it was opened. Please tell me urgently how to do it, using webdav or else. Thanks Akhil Gupta __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ From w3c-dist-auth-request@w3.org Tue Mar 5 17:26: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 RAA03239 for ; Tue, 5 Mar 2002 17:26:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06703; Tue, 5 Mar 2002 17:22:34 -0500 (EST) Resent-Date: Tue, 5 Mar 2002 17:22:34 -0500 (EST) Resent-Message-Id: <200203052222.RAA06703@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 RAA06660 for ; Tue, 5 Mar 2002 17:22:03 -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 RAA24054 for ; Tue, 5 Mar 2002 17:22:03 -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 OAA05970; Tue, 5 Mar 2002 14:22:05 -0800 (PST) From: "Jim Whitehead" To: "akhil gupta" , Date: Tue, 5 Mar 2002 14:22:18 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20020305150740.58526.qmail@web11006.mail.yahoo.com> Subject: RE: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6037 X-Loop: w3c-dist-auth@w3.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 > Can you please tell me how using the webdav we can > save files on internet, means i want to write a > program for opening a file through a site of the > format of MS Word or Excel, edit it and save it back > on the remote computer, from where it was opened. > Please tell me urgently how to do it, using webdav or > else. > There are many libraries that can be used to access a WebDAV repository and achieve the goals you describe. A list of these APIs can be found at: http://www.ics.uci.edu/pub/ietf/webdav/ (look about 1/2 way down the page) The file can be retrieved using the GET method (standard HTTP/1.1). Using the WebDAV LOCK method will ensure that only one person can edit the file at a time. As for actually editing a .doc or .xls file, this requires knowledge of the internal structure of these file formats. The WebDAV protocol does not know anything about these file formats -- it's out of scope. Reading the following paper may give you some insight into the high-level design goals for WebDAV: http://www.cs.ucsc.edu/~ejw/papers/dav-ecscw.pdf - Jim From w3c-dist-auth-request@w3.org Wed Mar 6 04:32: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 EAA28389 for ; Wed, 6 Mar 2002 04:32:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA12585; Mon, 4 Mar 2002 18:39:27 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 18:39:27 -0500 (EST) Resent-Message-Id: <200203042339.SAA12585@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 SAA12564 for ; Mon, 4 Mar 2002 18:39:03 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA12706 for ; Mon, 4 Mar 2002 18:39:02 -0500 Received: from 10.196.0.11 by mail.4d.com; Mon, 4 Mar 2002 15:39:02 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 4 Mar 2002 15:36:50 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6030 X-Loop: w3c-dist-auth@w3.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 "Translate" is much clearer than "DAV-Enabled" because it at least >it says what you want. Then let's spec Translate and make it part of DAV. Interoperable implementations exist. >As I've said numerous times: make up your mind whether the source and it's >output are the same resource or not. If they are, you can use "Translate". >If they aren't, they will have different URLs. They are if the administrator says they are. Again, that's policy. I don't set policy, I just make the tools my users want. >HTTP takes the position that they are different resources (see introduction >to "GET"), and I don't see how a different working group could change this >view. The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process. If DAV is responsible for processing GET, and it makes the policy decision that the correct output is the the same as the source text (and the security sub-system gives the go-ahead) then it should be able to return the source text if that's the policy. > > I don't see that > > it would be so horrible to allow the idea that one of the >> representations of a resource could be its raw source. What > >The most horrible thing being that the source resource doesn't have it's own >URL and thus cannot be properly referred to using just a URL. Could you >please explain why you think this particular problem *isn't* relevant? Because in practice most people don't want to view the source in a browser. They use DAV for working with their source, and they only use it for working with their source. > >> representation you receive is a matter of server policy. And some >> way of identifying that the server is talking to a DAV client would >> help with managing that policy. > >No, "DAV-Enabled" vs. "Translate" is the completely wrong approach. >Following your proposal, a "DAV enabled" client never would want to GET the >output resource. Sure you could. If the administrator decides that's a good thing, and wants to separate the URIs for source and display, then you could certainly GET the output resource with your DAV client. And if DAV:source ever gets fixed and implemented then you could even have automatic linking between display and source URIs. Its all about how the administrator wants to set up the policy. cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 05:05:39 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 FAA28915 for ; Wed, 6 Mar 2002 05:05:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA15715; Mon, 4 Mar 2002 22:44:55 -0500 (EST) Resent-Date: Mon, 4 Mar 2002 22:44:55 -0500 (EST) Resent-Message-Id: <200203050344.WAA15715@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 WAA15268 for ; Mon, 4 Mar 2002 22:43:48 -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 UAA29193 for ; Mon, 4 Mar 2002 20:37:59 -0500 Received: from rgmgw6.us.oracle.com (rgmgw6.us.oracle.com [138.1.191.15]) by inet-mail4.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g251bwG09365 for ; Mon, 4 Mar 2002 17:37:58 -0800 (PST) Received: from esedlarlaptop (dhcp-4op7-4op8-east-130-35-171-59.us.oracle.com [130.35.171.59]) by rgmgw6.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g251bvV04763 for ; Mon, 4 Mar 2002 18:37:57 -0700 (MST) Message-ID: <004a01c1c3e6$59a7fb40$3bab2382@us.oracle.com> From: "Eric Sedlar" To: References: Date: Mon, 4 Mar 2002 17:37: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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6031 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit My comments inlined, with longer response at the end... ----- Original Message ----- From: "Julian Reschke" To: "Eric Sedlar" ; Sent: Monday, March 04, 2002 2:27 PM Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > Eric, > > thanks for taking the time to write this long reply. I am putting some > comments inline... > > > From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com] > > Sent: Monday, March 04, 2002 8:48 PM > > To: Julian Reschke; CJ Holmes; w3c-dist-auth@w3.org > > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > > > > It's not clear to me that the generated output from GET on executables > > actually is a different resource. First of all, it doesn't make sense to > > think of it as having properties separate from that of the > > script. I doubt > > It does. For instance, DAV:getcontenttype will almost certainly have a > different value, so will DAV:getcontentlength. > > > if anyone actually doing the URL space mapping proposed would > > keep around a > > set of dead properties for the generated output, but the case becomes > > clearer when looking at the live properties. > > Well, I wouldn't expect a server to store dead properties for a "output" > resource, but this is really an implementation detail. > > > If I have a directory full of .ASPs, or .JSP files, and I do a PROPFIND on > > that directory, will the server actually execute all of the scripts in the > > directory in order, dumping their output to a temp file, to ensure that > > dav:getcontentlength is correct? I bet nobody actually does that > > A conforming server will either report these properties as empty or as > non-existant (unless it's actually able to compute these values cheaply). > The point is that you will not be able to get and that have the correct values, which the spec pretty clearly states should be returned if it is a DAV-enabled resource. > > (it would > > be "considered harmful" like PROPFIND depth infinity), and if you did it > > would be stupid. I haven't checked this, but I bet that most > > servers return > > the length of the underlying script as the length of the > > generated output on > > IMHO this would be a bug. > Whatever. They return something other than the correct value. > > a PROPFIND depth 1. The same difficulties apply to and many > > other live properties. The reason this doesn't matter in practice is that > > returning the wrong etag or wrong content length for generated output is > > irrelevant, since in the general case it cannot be cached, and it works > > Why do you say that generated output can not be cached? A big part of the > HTTP spec treats this very problem. I say that in the GENERAL case it cannot be cached. For example, a script that returns the value of a row in a database table (say the current inventory total on Amazon.com of Harry Potter books) cannot be cached, since the return value is not simply a function of the input arguments in the request method. Those generated output entities that are strictly functions of the input arguments can be cached, by using the techniques in HTTP/1.1. > > > functionally just as if the resource was changed before the > > subsequent GET, > > so it's ok if the value of is different in a > > PROPFIND on > > its parent and the actual content length returned when you do a GET. > > > > I think that the better model is if you think of the GET method more like > > the "OPEN" action on Windows or Macintosh, which means to execute > > this file > > if executable, or else display the contents of the document. GET > > is really > > like a simple case of the POST method (which was originally how it was > > conceived). To illustrate this point, let's say that a particular server > > said that POST on a non-executable resource (like a static file) > > would dump > > its contents (like a GET). Now we can clearly see GET on a script as a > > simple case of POST. > > GET doesn't dump "the content" of a resource. GET returns an entity which is > one of many possible representations of the resource, which may depend on > non-URL based information in the headers (in which case these headers should > be listed in the "Vary" header). > > > Julian's argument below gets at the heart of the problem--is each set of > > possible output generated by a script a different resource? First of all, > > there are many different things that can affect the output of a resource, > > and most of them are not in the URL (which is the only thing that can be > > used to differentiate two resources). While the URL arguments in > > the query > > string are one set of arguments to the script, clearly information in the > > header may also be used (even in a GET method). For example, the > > Yes. > > > authentication headers may be used to choose whose shopping cart will be > > displayed, or in POST, the form values appear in headers. If, as Julian > > suggests: GET /foo/my.jsp?arg1=val1 is a different resource than GET > > /foo/my.jsp?arg1=val2, then POST /foo/my.jsp with a header Arg1: > > GET ... is not a resource, it's one representation of a resource. > > URLs (as they are URIs as defined in RFC2396) identify resources. If they > differ, this is a good indication that the resource they identify differs as > well. > > > val1 should > > be different than POST /foo/my.jsp with header Arg1: val2. This obviously > > makes no sense. > > I don't understand the analogy to POST. POST is very different from GET in > it's semantics (it's not just a distinction in marshalling). > Why is POST different in semantics from GET? Since we are confining ourselves to discussing generated output, I see them as just having different ways of marshalling arguments. > > So, here are my arguments for why each possible output generated > > by a script > > should not be a separate resource: > > I didn't say that. What I'm saying is that the set of outputs (that can be > generated by a GET on a URL) is a different resource than the source > resource. > > > * they may not have separate URLs, since not all of the arguments > > that cause > > different output may be in the URL string--they may be in headers, or may > > depend on other server state > > That's fine. So all of them are the same abstract resource. > > > * it is impractical to manage dead properties for each possible output > > That's no problem. If you don't want to, don't. > > > * it is computationally difficult to return dead properties (such as > > dav:getcontentlength) for each possible output > > Again fine. Don't return them. > > > Therefore, I conclude that generated output is not a resource, and > > You can't conclude that, because the generated output *has* a URL, so it > *must* be a representation of an abstract resource. > > > especially not a dav-enabled resource. I would recommend that server > > implementers NOT return script output as dav enabled. > > That's fine. You don't have to. > > > Now, on to the practical argument, which will demonstrate that > > dav:source is > > a lot less usable than GETSRC/Translate: > > > > let's say that I have a directory full of scripts and static > > files. I want > > to manage them from a authoring point of view. If I want to implement > > dav:source, I need to create some virtual URL space that > > corresponds to the > > physical URL space where the actual script source is stored. I > > Actually, I'd say that you should create mappings for the outputs, not for > the sources, but this is just a matter of taste, I guess. > That option is covered in case #2. > > can make the > > virtual URL space return either the generated output, or the source, at > > least from an implementation point of view. For example: > > > > Contents of /mydir: > > > > foo.jsp > > bar.html > > bar.gif > > > > In case 1, let's say I make /scripts/src/ a virtual URL space > > that returns the source of any executables (for DAV clients), so where GET > > /mydir/foo.jsp will return the generated output, > > /scripts/src/mydir/foo.jsp > > will return the source. dav:source on /mydir/foo.jsp will point to > > /scripts/src/mydir/foo.jsp. The DAV client doesn't actually want to mess > > with /mydir/foo.jsp since it is generated, has bogus live property values, > > doesn't respond to things like PUT, and is generally not very > > helpful. Now > > I'm forced into a separate tree, which is certainly annoying from a > > That's something the client should do for you. > It can't do this easily, because it doesn't know the general rule of mapping the generated output URL to the source, it just knows the answer on a URL by URL basis. > > useability point of view, and extremely annoying when doing things like > > copying with Web Folders, since when I drag & drop my app from the local > > filesystem to the server, my .jsp files move to another place, and when I > > copy the application back down to my local PC, the .jsps were > > moved (even if > > I was smart enough to realize where they magically went to). So, > > this is a > > bad solution. > > Why don't you just edit *all* files in the source directory and leave the > output resources alone? > See case #2, below, again. > > In case 2, let's say I make /script/output/ a virtual URL space > > that returns the generated output for the executables. Now the DAV client > > is happy, since the server space looks like the space on the client. > > Unfortunately, all of the tags in any HTML output are > > screwed up vs. > > the local copy (e.g if bar.html wanted a link to foo.jsp, or vice versa), > > since neither a relative nor an absolute URL will work, and the > > URLs needed > > are server implementation-dependent. > > Julian, you have suggested that case #2 is the preferred solution (creating the virtual URL space for the generated resources), but you haven't addressed the linking problem between the static & generated content. You have not given a complete suggestion. > > The reality of the world is that people want to be able to move their > > content creation environment back and forth between local filesystems and > > DAV servers. Any usage of dav:source would break that abstraction, since > > local filesystems aren't capable of implementing virtual URL spaces. I > > Again, that's not true. You can author the *source* URL space just like > always. All you need the DAV:source property for is to discover where those > files sit. > Are you suggesting that when dragging & dropping some Web Folders down from a server, the client should examine the dav:source properties, and copy down the entities returned by GET on those URLs those represent, rather than the entities returned by the original URLs? While this could be done, it certainly breaks backwards compatability with almost all existing DAV clients. Plus, it could result in multiple copies of the source after the download. > > think these are the practical reasons why nobody has implemented > > dav:source > > in the past 3 years. > > The DAV:source property is underspecified in the spec, that's the reason > it's not implemented. That doesn't make the concept itself bad. What part of dav:source is underspecified? I think it is pretty clear from the spec. It just doesn't solve the problem in a usable way. > > > So, it is clear that: > > > > * generated output (from stuff like .jsps, .asps, cgi) does not make sense > > as a DAV-enabled resource, since the only methods it is likely to > > respond to > > intelligently is GET. > > I don't have any problem with this. If output resources aren't WEBDAV > enabled, you just lose the ability to use DAV:source to discover their > sources. > > > * separating the URL space of generated output and source causes usability > > problems, making life awkward either for the DAV client, or for the HTML > > linking > > I don't agree. > That's because you aren't considering backwards compatability. > > I think the argument for a GETSRC method becomes clear if you mentally > > rename GET to LIMITED-VERSION-OF-POST. > > GET and POST are fundamentelly different things. > Why are they so fundamentally different? > > Reponses to a couple of other points in more recent emails: > > > > Alan Babich says: > > > > "Is the source the same entity as its output?" Julian and I agree > > that it is > > not. RFC2616 section 9.3 says it is not. > > > > Response: the issue is not whether or not the source and the output are > > the same "entity", but the same DAV resource. Entity and resource are > > ...the same HTTP resource... > > > different things. There are three general categories of things that can > > Yes. > > > cause the output of a generated script to vary: URL information, e.g. the > > query string; header information; or server-state (like in a database). > > Clearly the URL isn't sufficient to differentiate between all the kinds of > > server-generated output, so the various entities that can be > > generated by a > > script cannot be mapped as separate resources, since they won't have > > separate URLs. > > If they don't have separate URLs, they aren't different abstract resources. > In the case of the shopping cart mentioned earlier, the resource identified > by the URL is "the shopping cart of the currently logged in user". It's no > problem if it's different for different users. > > > Roy Fielding says: > > > > Any server that allows clients to vary GET responses based on the > > Translate > > header field MUST include "Vary: Translate" in every response to the GET > > method in order to remain compliant with HTTP/1.1. > > > > Response: Actually, RFC2616 says: "An HTTP/1.1 server SHOULD include a > > Vary header field with any cacheable response that is subject to > > server-driven negotiation." So, clearly, Microsoft is in compliance with > > the HTTP specification since this is not a MUST requirement. > > SHOULD (as defined in RFC2119): > > "This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course." > > To still claim conformance, one would have to specify these valid reasons. > Can you think of any? > I'm sure MSFT could come up with some valid backwards-compatability reasons or something. The point is that an HTTP/1.1 client cannot expect anything with SHOULD to always be the case > > Clearly it is > > acceptable to use header values to vary the content of generated state, > > Yes, but by doing to you state that all entities that you return are > representations of the same resource. Are they? > > > whether it be the Translate header or the Authentication header, > > and whether > > or not the Vary header is supplied is a completely orthogonal issue. > > Yes. But you SHOULD indicate it in the "Vary" header. > Great. We can agree that the Vary header is a side issue and not relevant for the purposes of this discussion. > > Here's another way to look at the categorization of response entities for > > executables: > > > > 1) the source > > 2) generated output that does not vary based on input arguments > > from client > > 3) generated output varying with input arguments from client encoded in > > query string > > 4) generated output varying with input arguments from client encoded in > > request headers > > 5) generated output varying with server-side state (like information in a > > database) > > > > I don't see why case #2 and case #3 (in Julian's example) should > > be awarded > > its own status as a "real dav resource" when cases #4 and #5 are not. > > Because resources are *identified* by their URLs. If the URL is the same, > it's *by definition* the same resource. > Now you are arguing circularly. You say that because the source and generated output are different resources, they should have different URLs. Now you are saying that because they have different URLs, they are different resources. > > I'd like to see someone propose a scheme for implementing dav:source that > > solves the usability problem when mapping to the local filesystem, if they > > believe in dav:source. > > First of all, I strongly object to this line of argument. Even *if* you can > demonstrate that DAV:source as it is doesn't work, this doesn't mean that > this makes the Translate header an acceptable solution. > > This having said, I don't see any problem having two separate URL spaces, > and to only author the source space. The output space *may* be DAV enabled, > and if it is, it should use DAV:source or something similar we'll come up > with to indicate where the source is. > My line of argument is that having a separate URL space for generated output from the underlying executable doesn't work well because: * the generated "resources" won't have the correct values for many live properties (other than dav:source!!!), and will probably (your words) not support dead properties * the generated "resources" will only respond to the GET method, not other WebDAV methods * creating a virtual URL space for generated outputs (as you suggest) makes the linking unworkable when doing the 1-1 sitecopy semantics between local filesystems & servers that is common practice today, thus making the separate URL space idea unusable if backwards compatability is maintained. * just because the response body is different based on the Translate: header isn't really a different argument than having a different response body by varying the authentication header. By this argument, each possible response body that can be altered by varying a header is a different resource, which clearly does not make sense. dav:source is an implementation suggestion that requires separate URL spaces. GETSRC/Translate are various ways of handling the generated output as the same URL. My argument is against the separate URL space, not the dav:source header as specified by RFC2518, which most people seem to agree is broken (you believe it is underspecified, and I believe it is the wrong architecture). Julian, fundamentally your response is self-contradictory. At one point, you say: 1) "the set of outputs (that can be generated by a GET on a URL) is a different resource than the source resource". but later you say that: 2) "Because resources are *identified* by their URLs. If the URL is the same, it's *by definition* the same resource". If a set of generated outputs is generated differently by varying parameters in the query string, statement #1 would imply that the entire set of valid outputs is one resource. Statement #2 implies that this set is a bunch of different resources, since their URL is different. You are using a different number of resources per executable at different points to reply to different points in my argument. I'm saying there is one resource, used for the script & generated output. At first you are proposing 2, and later you propose n, where n is the number of possible combinations of legal input querystring values. Which is it? Julian's other argument is that you might want to have existing clients be able to edit the source just by pointing to some URL. Well, without understanding dav:source they won't know what the URL is to use for the next GET method. So, clearly clients will need to be upgraded either to handle Translate:/GETSRC or to handle the dav:source header. Existing clients won't cut it, so I don't by this reasoning, anyway. --Eric From w3c-dist-auth-request@w3.org Wed Mar 6 07:49:35 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 HAA05078 for ; Wed, 6 Mar 2002 07:49:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA25485; Wed, 6 Mar 2002 07:47:33 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 07:47:33 -0500 (EST) Resent-Message-Id: <200203061247.HAA25485@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 HAA25465 for ; Wed, 6 Mar 2002 07:47:19 -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 HAA13387 for ; Wed, 6 Mar 2002 07:47:18 -0500 Received: (qmail 23490 invoked by uid 0); 6 Mar 2002 12:46:46 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 6 Mar 2002 12:46:46 -0000 From: "Julian Reschke" To: "Eric Sedlar" , Date: Wed, 6 Mar 2002 13:46:45 +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: <004a01c1c3e6$59a7fb40$3bab2382@us.oracle.com> Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6039 X-Loop: w3c-dist-auth@w3.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, comments inline.... > > A conforming server will either report these properties as empty or as > > non-existant (unless it's actually able to compute these values > cheaply). > > > > The point is that you will not be able to get and > that have the correct values, which the spec pretty clearly > states should be returned if it is a DAV-enabled resource. Sorry? If your output is dynamically generated, you won't be able to supply a content-length header upon GET (or HEAD) either (unless you compute the result first before sending the headers). So it's perfectly acceptable not to return a DAV:getcontentlength for resources like these. > > > (it would > > > be "considered harmful" like PROPFIND depth infinity), and if > you did it > > > would be stupid. I haven't checked this, but I bet that most > > > servers return > > > the length of the underlying script as the length of the > > > generated output on > > > > IMHO this would be a bug. > > > > Whatever. They return something other than the correct value. Eric, not returning a value if you don't have it (and won't have it upon GET) is correct. > > > a PROPFIND depth 1. The same difficulties apply to > and many > > > other live properties. The reason this doesn't matter in practice is > that > > > returning the wrong etag or wrong content length for > generated output is > > > irrelevant, since in the general case it cannot be cached, > and it works > > > > Why do you say that generated output can not be cached? A big > part of the > > HTTP spec treats this very problem. > > I say that in the GENERAL case it cannot be cached. For example, a script > that returns the value of a row in a database table (say the current > inventory total on Amazon.com of Harry Potter books) cannot be > cached, since > the return value is not simply a function of the input arguments in the > request method. Those generated output entities that are > strictly functions > of the input arguments can be cached, by using the techniques in HTTP/1.1. Others can be cached as well. For instance, a GET on http://www.cnn.com (clearly something that falls under the category you just mentioned) tells me that I can cache the resullt for 60 seconds: > wget -S www.cnn.com --13:07:43-- http://www.cnn.com/ => `index.html' Connecting to www.cnn.com:80... connected! HTTP request sent, awaiting response... 200 OK 2 Server: Netscape-Enterprise/4.1 3 Date: Wed, 06 Mar 2002 12:07:42 GMT 4 Last-modified: Wed, 06 Mar 2002 12:07:43 GMT 5 Expires: Wed, 06 Mar 2002 12:08:43 GMT 6 Cache-control: private,max-age=60 7 Content-type: text/html 8 Connection: close > > I don't understand the analogy to POST. POST is very different > from GET in > > it's semantics (it's not just a distinction in marshalling). > > > > Why is POST different in semantics from GET? Since we are confining > ourselves to discussing generated output, I see them as just having > different ways of marshalling arguments. GET gets a representation of the resource (without affecting it). POST (possibly) modifies the resource. > > > can make the > > > virtual URL space return either the generated output, or the > source, at > > > least from an implementation point of view. For example: > > > > > > Contents of /mydir: > > > > > > foo.jsp > > > bar.html > > > bar.gif > > > > > > In case 1, let's say I make /scripts/src/ a > virtual URL space > > > that returns the source of any executables (for DAV clients), so where > GET > > > /mydir/foo.jsp will return the generated output, > > > /scripts/src/mydir/foo.jsp > > > will return the source. dav:source on /mydir/foo.jsp will point to > > > /scripts/src/mydir/foo.jsp. The DAV client doesn't actually want to > mess > > > with /mydir/foo.jsp since it is generated, has bogus live property > values, > > > doesn't respond to things like PUT, and is generally not very > > > helpful. Now > > > I'm forced into a separate tree, which is certainly annoying from a > > > > That's something the client should do for you. > > > > It can't do this easily, because it doesn't know the general rule > of mapping > the generated output URL to the source, it just knows the answer > on a URL by > URL basis. Maybe this indicates that the protocol should allow a server to say that all source resources for the output resources in a collection sit in some specific other collection. I admit that if this is the case and the server indicates this, thing for clients would be much easier. > > > In case 2, let's say I make /script/output/ a virtual URL > space > > > that returns the generated output for the executables. Now the DAV > client > > > is happy, since the server space looks like the space on the client. > > > Unfortunately, all of the tags in any HTML output are > > > screwed up vs. > > > the local copy (e.g if bar.html wanted a link to foo.jsp, or vice > versa), > > > since neither a relative nor an absolute URL will work, and the > > > URLs needed > > > are server implementation-dependent. > > > > > Julian, you have suggested that case #2 is the preferred solution > (creating > the virtual URL space for the generated resources), but you haven't > addressed the linking problem between the static & generated content. You > have not given a complete suggestion. I'm not sure that I understand the issue. If you're talking about broken links -- can't you use relative URI references instead? > > > The reality of the world is that people want to be able to move their > > > content creation environment back and forth between local filesystems > and > > > DAV servers. Any usage of dav:source would break that abstraction, > since > > > local filesystems aren't capable of implementing virtual URL > spaces. I > > > > Again, that's not true. You can author the *source* URL space just like > > always. All you need the DAV:source property for is to discover where > those > > files sit. > > > > Are you suggesting that when dragging & dropping some Web Folders > down from > a server, the client should examine the dav:source properties, > and copy down > the entities returned by GET on those URLs those represent, > rather than the > entities returned by the original URLs? While this could be done, it > certainly breaks backwards compatability with almost all existing DAV > clients. Plus, it could result in multiple copies of the source after the > download. I think this is what the spec says. I would expect that the result of COPYing is the same as GETting and PUTting to a new location. I certainly wouldn't expect to have the source code in one case and it's output in the other case. > > > think these are the practical reasons why nobody has implemented > > > dav:source > > > in the past 3 years. > > > > The DAV:source property is underspecified in the spec, that's the reason > > it's not implemented. That doesn't make the concept itself bad. > > What part of dav:source is underspecified? I think it is pretty > clear from > the spec. It just doesn't solve the problem in a usable way. See . > > > * separating the URL space of generated output and source causes > usability > > > problems, making life awkward either for the DAV client, or > for the HTML > > > linking > > > > I don't agree. > > > > That's because you aren't considering backwards compatability. With...? > > > I think the argument for a GETSRC method becomes clear if you mentally > > > rename GET to LIMITED-VERSION-OF-POST. > > > > GET and POST are fundamentelly different things. > > > > Why are they so fundamentally different? Because of their definition in the HTTP protocol? > > > Response: Actually, RFC2616 says: "An HTTP/1.1 server > SHOULD include > a > > > Vary header field with any cacheable response that is subject to > > > server-driven negotiation." So, clearly, Microsoft is in compliance > with > > > the HTTP specification since this is not a MUST requirement. > > > > SHOULD (as defined in RFC2119): > > > > "This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course." > > > > To still claim conformance, one would have to specify these > valid reasons. > > Can you think of any? > > > > I'm sure MSFT could come up with some valid > backwards-compatability reasons > or something. The point is that an HTTP/1.1 client cannot expect anything > with SHOULD to always be the case Which means that implementing Translate without setting the Translate header *will* break caching in proxies. > > > Here's another way to look at the categorization of response entities > for > > > executables: > > > > > > 1) the source > > > 2) generated output that does not vary based on input arguments > > > from client > > > 3) generated output varying with input arguments from client > encoded in > > > query string > > > 4) generated output varying with input arguments from client > encoded in > > > request headers > > > 5) generated output varying with server-side state (like > information in > a > > > database) > > > > > > I don't see why case #2 and case #3 (in Julian's example) should > > > be awarded > > > its own status as a "real dav resource" when cases #4 and #5 are not. > > > > Because resources are *identified* by their URLs. If the URL is > the same, > > it's *by definition* the same resource. > > > > Now you are arguing circularly. You say that because the source and > generated output are different resources, they should have different URLs. Yes. > Now you are saying that because they have different URLs, they > are different > resources. Did I say that? - Resources (RFC 2616): "A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways." - URI (RFC 2616) "As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic--a resource." So if two things have the same URI, they *must* be the same resource (by RFC terminology). If the URIs differ, they *may* be different resources. > My line of argument is that having a separate URL space for > generated output > >from the underlying executable doesn't work well because: > > * the generated "resources" won't have the correct values for many live > properties (other than dav:source!!!), and will probably (your words) not > support dead properties Not having values is something different from not having "correct" ones. I simply don't see a problem here. > * the generated "resources" will only respond to the GET > method, not other > WebDAV methods Define "respond". They may not *implement* or *support* some other methods, right. > * creating a virtual URL space for generated outputs (as you suggest) > makes the linking unworkable when doing the 1-1 sitecopy semantics > between local filesystems & servers that is common practice today, thus > making the separate URL space idea unusable if backwards compatability is > maintained. I think it is *also* common practice to replicate the source URL spaces (and not to touch the output URL spaces at all). In which case there's no problem. > * just because the response body is different based on the Translate: > header isn't really a different argument than having a different response > body by varying the authentication header. By this argument, > each possible > response body that can be altered by varying a header is a different > resource, which clearly does not make sense. I didn't say that. I asked the question: "do you consider the (ASP) source code and it's output the same resource or not"? If they are, they can share the same URL. If they aren't, they MUST not. HTTP (RFC2616) says they aren't. Varying the entity returned based on the time of day, the logged in user, it's accept-language header and similar things is something completely different from just returning the source code. > dav:source is an implementation suggestion that requires separate URL > spaces. GETSRC/Translate are various ways of handling the > generated output > as the same URL. My argument is against the separate URL space, not the > dav:source header as specified by RFC2518, which most people seem to agree > is broken (you believe it is underspecified, and I believe it is the wrong > architecture). > > Julian, fundamentally your response is self-contradictory. At one point, > you say: > > 1) "the set of outputs (that can be generated by a GET on a URL) is a > different resource than the source resource". Yes. > but later you say that: > > 2) "Because resources are *identified* by their URLs. If the URL is the > same, it's *by definition* the same resource". > > If a set of generated outputs is generated differently by varying > parameters > in the query string, statement #1 would imply that the entire set of valid > outputs is one resource. Statement #2 implies that this set is a bunch of No, it doesn't. If you vary parameters in the query string, you are using *different* URLs. Statement 1 talks about the set of outputs generated by GETs on a (*specific*) URL. > different resources, since their URL is different. You are using a > different number of resources per executable at different points > to reply to > different points in my argument. I'm saying there is one > resource, used for > the script & generated output. At first you are proposing 2, and > later you > propose n, where n is the number of possible combinations of legal input > querystring values. Which is it? No, I didn't. What I'm saying is that: - A URL identifies a resource. GETs on that URL return different representations of the same resource. - If the URLs differ (by varying the query string), they *may* identify different resources (but they don't have to). For instance, I'd consider http://server/foo?test=1 and http://server/foo?test=2 different resources, but http://server/foo?a=1&b=2 and http://server/foo?b=2&a=1 the same resource (but to do this, you'll have to have special knowledge about the treatment of query parameters) > Julian's other argument is that you might want to have existing clients be > able to edit the source just by pointing to some URL. Well, without > understanding dav:source they won't know what the URL is to use > for the next > GET method. So, clearly clients will need to be upgraded either to handle > Translate:/GETSRC or to handle the dav:source header. Existing clients > won't cut it, so I don't by this reasoning, anyway. Yes, clients and servers will need to be upgraded. Did I say otherwise? Julian From w3c-dist-auth-request@w3.org Wed Mar 6 08:29:11 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 IAA06777 for ; Wed, 6 Mar 2002 08:29:11 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA20985; Wed, 6 Mar 2002 07:02:36 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 07:02:36 -0500 (EST) Resent-Message-Id: <200203061202.HAA20985@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 HAA20672 for ; Wed, 6 Mar 2002 07:01: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 HAA07425 for ; Wed, 6 Mar 2002 07:01:50 -0500 Received: (qmail 23467 invoked by uid 0); 6 Mar 2002 12:01:18 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 6 Mar 2002 12:01:18 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Wed, 6 Mar 2002 13:01:18 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6038 X-Loop: w3c-dist-auth@w3.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 CJ, > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > Sent: Tuesday, March 05, 2002 12:37 AM > To: DAV > Subject: Translate (was RE: DAV-Enabled field (was RE: A case for > GETSRC)) > > > >I think "Translate" is much clearer than "DAV-Enabled" because > it at least > >it says what you want. > > Then let's spec Translate and make it part of DAV. Interoperable > implementations exist. Just because there's a proposal that I think is even worse doesn't make the Translate header a good solution. If you want to go ahead, you'll have to: 1) Clearly define what Translate means for every HTTP method defined in HTTP 1.1, WebDAV (and preferably ACL and deltaV). 2) Note that ths definition must be compatible with what the base specs do today. > >As I've said numerous times: make up your mind whether the > source and it's > >output are the same resource or not. If they are, you can use > "Translate". > >If they aren't, they will have different URLs. > > They are if the administrator says they are. Again, that's policy. > I don't set policy, I just make the tools my users want. I personally do not agree that this is a question of policy. It should be *consistent*. > >HTTP takes the position that they are different resources (see > introduction > >to "GET"), and I don't see how a different working group could > change this > >view. > > The GET method means retrieve whatever information (in the form of an > entity) is identified by the Request-URI. If the Request-URI refers > to a data-producing process, it is the produced data which shall be > returned as the entity in the response and not the source text of the > process, unless that text happens to be the output of the process. > > If DAV is responsible for processing GET, and it makes the policy > decision that the correct output is the the same as the source text > (and the security sub-system gives the go-ahead) then it should be > able to return the source text if that's the policy. DAV is not responsible for "processing" anything. DAV defines semantics of new HTTP methods, and in particular, it doesn't define GET. > > > I don't see that > > > it would be so horrible to allow the idea that one of the > >> representations of a resource could be its raw source. What > > > >The most horrible thing being that the source resource doesn't > have it's own > >URL and thus cannot be properly referred to using just a URL. Could you > >please explain why you think this particular problem *isn't* relevant? > > Because in practice most people don't want to view the source in a > browser. They use DAV for working with their source, and they only > use it for working with their source. It's not a question of seeing the source in a browser, it's about being able to *refer* to it. What do you do when somebody sends an email asking for a link to the source resource? Do you send the URL and add wording to explain what program will be needed to open it? > >> representation you receive is a matter of server policy. And some > >> way of identifying that the server is talking to a DAV client would > >> help with managing that policy. > > > >No, "DAV-Enabled" vs. "Translate" is the completely wrong approach. > >Following your proposal, a "DAV enabled" client never would want > to GET the > >output resource. > > Sure you could. If the administrator decides that's a good thing, > and wants to separate the URIs for source and display, then you could > certainly GET the output resource with your DAV client. And if > DAV:source ever gets fixed and implemented then you could even have > automatic linking between display and source URIs. Its all about > how the administrator wants to set up the policy. OK, so you agree that this is a problem with your proposal, while it isn't with separate URLs? From w3c-dist-auth-request@w3.org Wed Mar 6 09: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 JAA11044 for ; Wed, 6 Mar 2002 09:54:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA14211; Wed, 6 Mar 2002 09:53:37 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 09:53:37 -0500 (EST) Resent-Message-Id: <200203061453.JAA14211@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 JAA14191 for ; Wed, 6 Mar 2002 09:53:30 -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 JAA02939 for ; Wed, 6 Mar 2002 09:53:30 -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; Wed, 06 Mar 2002 09:51:20 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 09:52:59 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1060EE0EF@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 6 Mar 2002 09:52:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6040 X-Loop: w3c-dist-auth@w3.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 bottom line here for me is that the source is very different from the generated output from that source. Users care deeply about this difference. This means that you have to make it easy to pass around, from application to application, which one you want. Now we could require every application that passed around a reference to be upgraded to understand a set of syntactic extensions that would tell each client along the way what headers, or what alternative methods, should be used to get the contents or otherwise manipulate the intended meaning of that resource, *OR* we could require that a server come up with a different URL, so that all of the existing URL passing machinery (e.g. pasting the URL in an email message) continues to work. Given the relative cost of getting consensus on these syntactic extensions (and getting all applications/users to adhere to them) vs. the cost of generating a source URL, the answer to me is clear. There are some points that are worth addressing, such as "how can a server tell a client that a corresponding tree of authoring resources is available". I (and I'm sure Julian) would agree that this is the kind of thing we need to fix about the DAV:source mechanism. In this case, a straightforward approach is to define that the DAV:source of a collection is another collection containing all the sources for members of that collection. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Mar 6 12:05: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 MAA18597 for ; Wed, 6 Mar 2002 12:05:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA02724; Wed, 6 Mar 2002 12:00:43 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 12:00:43 -0500 (EST) Resent-Message-Id: <200203061700.MAA02724@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 MAA02685 for ; Wed, 6 Mar 2002 12:00:20 -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 MAA30507 for ; Wed, 6 Mar 2002 12:00:20 -0500 Received: from localhost [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 06 Mar 2002 17:59:47 +0100 Date: Wed, 6 Mar 2002 17:59:47 +0100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Stefan Eissing To: w3c-dist-auth@w3.org In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1060EE0EF@SUS-MA1IT01> Message-Id: <909BDA94-3123-11D6-9FD1-00039384827E@greenbytes.de> 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id MAA02685 Subject: Re: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6041 X-Loop: w3c-dist-auth@w3.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 Am Mittwoch den, 6. März 2002, um 15:52, schrieb Clemm, Geoff: > [...] > There are some points that are worth addressing, such as "how can a > server tell a client that a corresponding tree of authoring resources > is available". I (and I'm sure Julian) would agree that this is the > kind of thing we need to fix about the DAV:source mechanism. In this > case, a straightforward approach is to define that the DAV:source of > a collection is another collection containing all the sources for > members of that collection. If there is a single source for a resource, the client is free to GET the source and store it locally under the name of the resource. It then only needs to remember the source uri for the PUT when changes need to be applied. I think this is trivial for a client to do. So, with a little effort on the client side, the user will experience the same behaviour as with the broken Translate header. The problem to solve is when to add sources to a copied tree. Where shall the client perform the PUT? Maybe this is something for the parent collection to hint at. For new collections, this could be recursively applied when uploading changes to a server. //Stefan From w3c-dist-auth-request@w3.org Wed Mar 6 14:15:39 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 OAA28851 for ; Wed, 6 Mar 2002 14:15:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA23987; Wed, 6 Mar 2002 14:13:55 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 14:13:55 -0500 (EST) Resent-Message-Id: <200203061913.OAA23987@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 OAA23935 for ; Wed, 6 Mar 2002 14:13:36 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA27115 for ; Wed, 6 Mar 2002 14:13:36 -0500 Received: from 10.196.0.11 by mail.4d.com; Wed, 6 Mar 2002 11:13:23 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 11:08:33 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6042 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > >No, "DAV-Enabled" vs. "Translate" is the completely wrong approach. >> >Following your proposal, a "DAV enabled" client never would want >> to GET the >> >output resource. >> >> Sure you could. If the administrator decides that's a good thing, >> and wants to separate the URIs for source and display, then you could >> certainly GET the output resource with your DAV client. And if >> DAV:source ever gets fixed and implemented then you could even have >> automatic linking between display and source URIs. Its all about >> how the administrator wants to set up the policy. > >OK, so you agree that this is a problem with your proposal, while it isn't >with separate URLs? No, I don't agree that this is a problem. In most cases it is the _desired_ effect because users generally only use DAV for messing with their source, and they don't care about using DAV with the output. But they _do_ want to use the same URLs for both editing source and viewing output. If the administrator wants something different he should be able to configure his server accordingly. Separating "source" and "display" into different resources with different URIs is a very nice idea, but not terribly useful to most people. Maybe once the DAV:source property is fixed and DASL gets off the ground, this will become a more useful configuration. I believe the DAV spec needs to allow both scenarios, and the simplest way to do that is to either: - have a definitive way to know when a client expects the source or - know when a GET method originates from a DAV client cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 14:22: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 OAA29433 for ; Wed, 6 Mar 2002 14:22:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA25026; Wed, 6 Mar 2002 14:20:56 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 14:20:56 -0500 (EST) Resent-Message-Id: <200203061920.OAA25026@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 OAA24973 for ; Wed, 6 Mar 2002 14:20:33 -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 OAA28266 for ; Wed, 6 Mar 2002 14:20:33 -0500 Received: (qmail 17913 invoked by uid 0); 6 Mar 2002 19:20:01 -0000 Received: from pd9535f1f.dip.t-dialin.net (HELO lisa) (217.83.95.31) by mail.gmx.net (mp005-rz3) with SMTP; 6 Mar 2002 19:20:01 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Wed, 6 Mar 2002 20:19:58 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6043 X-Loop: w3c-dist-auth@w3.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: Wednesday, March 06, 2002 8:09 PM > To: DAV > Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for > GETSRC)) > ... > - have a definitive way to know when a client expects the source or > - know when a GET method originates from a DAV client Again: a DAV-client may want to do a GET on the output (for testing), while a non-DAV client may want to see the source code. So *this* distinction doesn't make any sense at all. From w3c-dist-auth-request@w3.org Wed Mar 6 14:29: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 OAA00064 for ; Wed, 6 Mar 2002 14:29:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26707; Wed, 6 Mar 2002 14:28:41 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 14:28:41 -0500 (EST) Resent-Message-Id: <200203061928.OAA26707@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 OAA26658 for ; Wed, 6 Mar 2002 14:28:20 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA29741 for ; Wed, 6 Mar 2002 14:28:21 -0500 Received: from 10.196.0.11 by mail.4d.com; Wed, 6 Mar 2002 11:28:23 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 11:24:43 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6044 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Now you are arguing circularly. You say that because the source and >> generated output are different resources, they should have different URLs. > >Yes. > >> Now you are saying that because they have different URLs, they >> are different >> resources. > >Did I say that? > >- Resources (RFC 2616): > >"A network data object or service that can be identified by a URI, as >defined in section 3.2. Resources may be >available in multiple representations (e.g. multiple languages, data >formats, size, and resolutions) or vary in >other ways." > >- URI (RFC 2616) > >"As far as HTTP is concerned, Uniform Resource Identifiers are simply >formatted strings which identify--via name, location, >or any other characteristic--a resource." > > >So if two things have the same URI, they *must* be the same resource (by RFC >terminology). If the URIs differ, they *may* be different resources. I think we can all agree on that. What we're disagreeing on is that the source can be the same URI as the output. They can be two views of the same resource. That is how most people think of it, and it would be practical to accomodate them. But the current spec is very inconvenient in that it effectively prevents it (without explicitly forbidding it). > > My line of argument is that having a separate URL space for >> generated output >> >from the underlying executable doesn't work well because: >> >> * the generated "resources" won't have the correct values for many live >> properties (other than dav:source!!!), and will probably (your words) not >> support dead properties > >Not having values is something different from not having "correct" ones. I >simply don't see a problem here. I think Eric mentioned that some of these values are required, so you can't not return them. > > * creating a virtual URL space for generated outputs (as you suggest) >> makes the linking unworkable when doing the 1-1 sitecopy semantics >> between local filesystems & servers that is common practice today, thus >> making the separate URL space idea unusable if backwards compatability is >> maintained. > >I think it is *also* common practice to replicate the source URL spaces (and >not to touch the output URL spaces at all). In which case there's no >problem. It is common because it is the only way to deploy DAV under the current spec. It causes no end of confusion amongst people who are deploying/using DAV for the first time. It is counter-intuitive, and is not really useful in most situations. > > Julian's other argument is that you might want to have existing clients be > > able to edit the source just by pointing to some URL. Well, without > > understanding dav:source they won't know what the URL is to use > > for the next > > GET method. So, clearly clients will need to be upgraded either to handle > > Translate:/GETSRC or to handle the dav:source header. Existing clients > > won't cut it, so I don't by this reasoning, anyway. > >Yes, clients and servers will need to be upgraded. Did I say otherwise? Someone claimed that Translate/GETSRC would require implementation changes. Eric was just pointing out that implementations have to change anyway because of these very issues, therefore the argument is irrelevant. cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 14:40: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 OAA00721 for ; Wed, 6 Mar 2002 14:40:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA03487; Wed, 6 Mar 2002 14:39:48 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 14:39:48 -0500 (EST) Resent-Message-Id: <200203061939.OAA03487@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 OAA03467 for ; Wed, 6 Mar 2002 14:39:41 -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 OAA00392 for ; Wed, 6 Mar 2002 14:39:40 -0500 Received: (qmail 8458 invoked by uid 0); 6 Mar 2002 19:39:09 -0000 Received: from pd9535f1f.dip.t-dialin.net (HELO lisa) (217.83.95.31) by mail.gmx.net (mp014-rz3) with SMTP; 6 Mar 2002 19:39:09 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Wed, 6 Mar 2002 20:39:08 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6046 X-Loop: w3c-dist-auth@w3.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: Wednesday, March 06, 2002 8:25 PM > To: DAV > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > > ... > >> * the generated "resources" won't have the correct values > for many live > >> properties (other than dav:source!!!), and will probably > (your words) not > >> support dead properties > > > >Not having values is something different from not having > "correct" ones. I > >simply don't see a problem here. > > I think Eric mentioned that some of these values are required, so you > can't not return them. I have to not return them if they don't exist. I can't return the headers upon HEAD or GET either. If you understand RFC2518 as saying that DAV:getcontentlength MUST be returned any may not be an empty string, this indicates that we need to fix RFC2518. > >I think it is *also* common practice to replicate the source URL > spaces (and > >not to touch the output URL spaces at all). In which case there's no > >problem. > > It is common because it is the only way to deploy DAV under the > current spec. It causes no end of confusion amongst people who are > deploying/using DAV for the first time. It is counter-intuitive, and > is not really useful in most situations. These are completely subjective arguments. Some people like the one approach, some like the other. > > > Julian's other argument is that you might want to have > existing clients be > > > able to edit the source just by pointing to some URL. Well, without > > > understanding dav:source they won't know what the URL is to use > > > for the next > > > GET method. So, clearly clients will need to be upgraded > either to handle > > > Translate:/GETSRC or to handle the dav:source header. > Existing clients > > > won't cut it, so I don't by this reasoning, anyway. > > > >Yes, clients and servers will need to be upgraded. Did I say otherwise? > > Someone claimed that Translate/GETSRC would require implementation > changes. Eric was just pointing out that implementations have to > change anyway because of these very issues, therefore the argument is > irrelevant. Agreed, unless somebody claims that "adopting" the Translate header can be done without breaking existing code. From w3c-dist-auth-request@w3.org Wed Mar 6 15:22: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 PAA03341 for ; Wed, 6 Mar 2002 15:22:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA10559; Wed, 6 Mar 2002 15:21:12 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 15:21:12 -0500 (EST) Resent-Message-Id: <200203062021.PAA10559@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 PAA10515 for ; Wed, 6 Mar 2002 15:20:52 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA07793 for ; Wed, 6 Mar 2002 15:20:53 -0500 Received: from 10.196.0.11 by mail.4d.com; Wed, 6 Mar 2002 12:20:55 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 12:15:22 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6047 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > It is common because it is the only way to deploy DAV under the > > current spec. It causes no end of confusion amongst people who are > > deploying/using DAV for the first time. It is counter-intuitive, and >> is not really useful in most situations. > >These are completely subjective arguments. Some people like the one >approach, some like the other. The argument may be subjective to you, but the number of dollars that have to be applied to remedy the situation are not. It's the most common support problem for every organization that we've seen deploy mod_dav, our DAV, or other DAV solutions. DAV + newbie users == high support costs. Any many, many of those phone calls and emails turn out to be users who don't read the little pamphlet/webpage that the IT department prints explaining that they have to use a different URL from their DAV client. Normally we fix support problems by fixing bugs, changing the default configuration, or making the UI more intuitive. What is frustrating about this problem is that it can't be fixed because of the DAV spec. There is no way to use a DAV client to modify source at the same URI as the output, even though that's what most people expect. Using DAV:source isn't an answer because: (1) everyone who advocates it agrees that DAV:source as specified now is insufficient. (2) In a general-purpose web server there is a very real messiness with trying to get the right DAV:source property onto all of the dynamically generated resources. A web server may have dozens of modules that dynamically generate content, all of which might have very different definitions the URI spaces that they handle. (3) I think client support for DAV:source (once the spec is fixed) will be a long time in coming because it will take time to understand the issues. (4) You don't get anything extra with DAV:source beyond what you could have with Translate. (Until DASL and friends make the scene, that is.) cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 15:29: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 PAA03747 for ; Wed, 6 Mar 2002 15:29:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12277; Wed, 6 Mar 2002 15:29:03 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 15:29:03 -0500 (EST) Resent-Message-Id: <200203062029.PAA12277@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 PAA12125 for ; Wed, 6 Mar 2002 15:28:39 -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 PAA09137 for ; Wed, 6 Mar 2002 15:28:39 -0500 Received: (qmail 15399 invoked by uid 0); 6 Mar 2002 20:28:02 -0000 Received: from pd9535f1f.dip.t-dialin.net (HELO lisa) (217.83.95.31) by mail.gmx.net (mp009-rz3) with SMTP; 6 Mar 2002 20:28:02 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Wed, 6 Mar 2002 21:27:52 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6048 X-Loop: w3c-dist-auth@w3.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: Wednesday, March 06, 2002 9:15 PM > To: DAV > Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) > > .. > > Using DAV:source isn't an answer because: > (1) everyone who advocates it agrees that DAV:source as > specified now is insufficient. OK, let's fix it. > (2) In a general-purpose web server there is a very real > messiness with trying to get the right DAV:source property onto all > of the dynamically generated resources. A web server may have dozens > of modules that dynamically generate content, all of which might have > very different definitions the URI spaces that they handle. It's not clear to me why in this scenario using the same URI would be better. > (3) I think client support for DAV:source (once the spec is > fixed) will be a long time in coming because it will take time to > understand the issues. That we'll have to see. > (4) You don't get anything extra with DAV:source beyond what > you could have with Translate. (Until DASL and friends make the > scene, that is.) I disagree. For instance, you get separate identifiers for separate things, conform to HTTP, do not invent new methods, don't break proxies (...to be continued...). The remark about DASL is interesting. Could you elaborate? From w3c-dist-auth-request@w3.org Wed Mar 6 15:48: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 PAA04838 for ; Wed, 6 Mar 2002 15:48:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA01183; Wed, 6 Mar 2002 14:32:51 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 14:32:51 -0500 (EST) Resent-Message-Id: <200203061932.OAA01183@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 OAA00273 for ; Wed, 6 Mar 2002 14:32:10 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA30978 for ; Wed, 6 Mar 2002 14:32:10 -0500 Received: from 10.196.0.11 by mail.4d.com; Wed, 6 Mar 2002 11:32:14 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 11:31:36 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6045 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes >> Sent: Wednesday, March 06, 2002 8:09 PM >> To: DAV >> Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for >> GETSRC)) >> ... >> - have a definitive way to know when a client expects the source or >> - know when a GET method originates from a DAV client > >Again: a DAV-client may want to do a GET on the output (for testing), while >a non-DAV client may want to see the source code. So *this* distinction >doesn't make any sense at all. There's nothing about GETSRC or Translate that would _prevent_ such a configuration. If the administrator wants to support that, then he can configure his server accordingly. cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 16:43: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 QAA08201 for ; Wed, 6 Mar 2002 16:43:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA19854; Wed, 6 Mar 2002 16:41:40 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 16:41:40 -0500 (EST) Resent-Message-Id: <200203062141.QAA19854@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 QAA19729 for ; Wed, 6 Mar 2002 16:41:08 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA24514 for ; Wed, 6 Mar 2002 16:41:04 -0500 Received: from 10.196.0.11 by mail.4d.com; Wed, 6 Mar 2002 13:41:04 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 13:38:08 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6050 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > (2) In a general-purpose web server there is a very real >> messiness with trying to get the right DAV:source property onto all >> of the dynamically generated resources. A web server may have dozens >> of modules that dynamically generate content, all of which might have >> very different definitions the URI spaces that they handle. > >It's not clear to me why in this scenario using the same URI would be >better. It would be better from the user's point of view. And it is easier from the server's point of view because the DAV module only has to worry about what is on the file system, not all possible URIs that might be supported by the sum total of all configurations of all modules running on the server. > > (4) You don't get anything extra with DAV:source beyond what >> you could have with Translate. (Until DASL and friends make the >> scene, that is.) > >I disagree. For instance, you get separate identifiers for separate things, >conform to HTTP, do not invent new methods, don't break proxies (...to be >continued...). Having separate identifiers is not a benefit. As I have explained repeatedly, it is often a detriment. *If* people want to view output with their DAV clients and view source with their browsers, *then* it is a benefit. Since the benefit of splitting the source/display views into separate resources/URIs is very situation-specific, it should not be mandatory. "Conform to HTTP" is debatable. Returning the source for a GET if that's the intended policy could be interpreted as compliant with the HTTP spec, if you hold your head just so. "Doesn't break proxies" is solvable with the Vary field, and is a minor implementation detail. In short, in most cases you don't get anything. >The remark about DASL is interesting. Could you elaborate? DASL makes things more interesting because it allows for searching on properties. You might have content with properties that need to be searchable, generated by sources with a very different set of properties. (eg: a single source document that generates several display documents with searchable properties of different values.) Since in this case you _want_ different properties between source/display views you get a real benefit from splitting them into separate resources with separate URIs. I confess to not having read the spec, but it sounds like ACL is interesting because you could allow the NaturalSciences department (as an example) to restrict GET, HEAD, and POST operations in some display spaces and assign authoring/editing rights internally in some other spaces. In short, it might allow for a very author-driven security system instead of an administrator-driven one (without resorting to editing .htaccess files). Still, if you had a way to differentiate between GET and GETSOURCE, you wouldn't necessarily benefit from splitting the source/display resource, but it still might be very convenient to do so. This is why I keep coming back to the desireability of DAV:source. It should be fixed, and its support encouraged. But there also needs to be room for people who prefer the simplicity of the single URI, who just use DAV for messing with source, and who don't benefit from differentiating source/display URIs. cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 17:08: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 RAA09648 for ; Wed, 6 Mar 2002 17:08:44 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23697; Wed, 6 Mar 2002 17:07:59 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 17:07:59 -0500 (EST) Resent-Message-Id: <200203062207.RAA23697@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 RAA23675 for ; Wed, 6 Mar 2002 17:07:38 -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 RAA30881 for ; Wed, 6 Mar 2002 17:07:39 -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; Wed, 06 Mar 2002 17:05:28 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 17:07:08 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B011@SUS-MA1IT01> From: "Clemm, Geoff" To: DAV Date: Wed, 6 Mar 2002 17:07:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: DAV-Enabled field (was RE: A case for GETSRC) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6051 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It sounds like we have come to an agreement on the benefits of having a separate URL, and on the benefits of having additional methods/headers that allow you to use the same URL. The problem with defining/allowing both techniques, is that some servers will end up only doing one or the other, and some clients will end up only doing one or the other. That means clients will only interoperate in this regard wrt to servers that do it "the same way". And for clients/servers that care about interoperation, they have to do both, adding to the complexity of those interoperable clients/servers (and interoperable clients/servers are the ones we want to encourage/support). This is a tradeoff decision where reasonable people can disagree, but for me, the cost to interoperability of "allowing both" outweighs the benefits of having a "simpler" alternative way of achieving the same effect of DAV:source. Cheers, Geoff -----Original Message----- From: CJ Holmes [mailto:cholmes@4d.com] DASL makes things more interesting because it allows for searching on properties. You might have content with properties that need to be searchable, generated by sources with a very different set of properties. (eg: a single source document that generates several display documents with searchable properties of different values.) Since in this case you _want_ different properties between source/display views you get a real benefit from splitting them into separate resources with separate URIs. I confess to not having read the spec, but it sounds like ACL is interesting because you could allow the NaturalSciences department (as an example) to restrict GET, HEAD, and POST operations in some display spaces and assign authoring/editing rights internally in some other spaces. In short, it might allow for a very author-driven security system instead of an administrator-driven one (without resorting to editing .htaccess files). Still, if you had a way to differentiate between GET and GETSOURCE, you wouldn't necessarily benefit from splitting the source/display resource, but it still might be very convenient to do so. This is why I keep coming back to the desireability of DAV:source. It should be fixed, and its support encouraged. But there also needs to be room for people who prefer the simplicity of the single URI, who just use DAV for messing with source, and who don't benefit from differentiating source/display URIs. cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 18:06: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 SAA13810 for ; Wed, 6 Mar 2002 18:06:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA27949; Wed, 6 Mar 2002 18:05:49 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 18:05:49 -0500 (EST) Resent-Message-Id: <200203062305.SAA27949@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 SAA27924 for ; Wed, 6 Mar 2002 18:05:40 -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 SAA10745 for ; Wed, 6 Mar 2002 18:05:40 -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; Wed, 06 Mar 2002 18:03:30 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 18:05:09 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B016@SUS-MA1IT01> From: "Clemm, Geoff" To: Webdav WG Date: Wed, 6 Mar 2002 18:05:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC2518bis: xml:lang (2.6) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6052 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian's position that the scope of an attribute should be as is defined in the XML spec, unless there is a compelling reason to do otherwise. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, February 21, 2002 3:36 AM To: Lisa Dusseault; Webdav WG Subject: RFC2518bis: xml:lang (2.6) 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 Wed Mar 6 18:08: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 SAA13932 for ; Wed, 6 Mar 2002 18:08:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA28176; Wed, 6 Mar 2002 18:07:32 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 18:07:32 -0500 (EST) Resent-Message-Id: <200203062307.SAA28176@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 SAA28107 for ; Wed, 6 Mar 2002 18:07:20 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA25722 for ; Wed, 6 Mar 2002 16:44:59 -0500 Received: from 10.196.0.11 by mail.4d.com; Wed, 6 Mar 2002 13:45:03 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 6 Mar 2002 13:44:40 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6053 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > >Again: a DAV-client may want to do a GET on the output (for >> testing), while >> >a non-DAV client may want to see the source code. So *this* distinction > > >doesn't make any sense at all. > > >> There's nothing about GETSRC or Translate that would _prevent_ such a >> configuration. If the administrator wants to support that, then he >> can configure his server accordingly. > >My remark referred to "know when a GET method originates from a DAV client", >no to "GETSRC" or the Translate header. I see your point. Defining "Translate: F" would probably be better than just knowing if the client is DAV-enabled, since that tells you if the client wants the source or not. That way you could have a client that could view output or source at the same URI. Otherwise you would have to define the DAV-Enabled field to only be sent when a client wanted to GET the source view of a resource, which is a little silly. cjh -- From w3c-dist-auth-request@w3.org Wed Mar 6 22:22: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 WAA25270 for ; Wed, 6 Mar 2002 22:22:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15595; Wed, 6 Mar 2002 15:54:59 -0500 (EST) Resent-Date: Wed, 6 Mar 2002 15:54:59 -0500 (EST) Resent-Message-Id: <200203062054.PAA15595@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 PAA15520 for ; Wed, 6 Mar 2002 15:54:16 -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 PAA14269 for ; Wed, 6 Mar 2002 15:54:16 -0500 Received: (qmail 15452 invoked by uid 0); 6 Mar 2002 20:53:41 -0000 Received: from pd9535f1f.dip.t-dialin.net (HELO lisa) (217.83.95.31) by mail.gmx.net (mp007-rz3) with SMTP; 6 Mar 2002 20:53:41 -0000 From: "Julian Reschke" To: "CJ Holmes" , "DAV" Date: Wed, 6 Mar 2002 21:53:33 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6049 X-Loop: w3c-dist-auth@w3.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: Wednesday, March 06, 2002 8:32 PM > To: DAV > Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for > GETSRC)) > > > > > From: w3c-dist-auth-request@w3.org > >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of CJ Holmes > >> Sent: Wednesday, March 06, 2002 8:09 PM > >> To: DAV > >> Subject: RE: Translate (was RE: DAV-Enabled field (was RE: A case for > >> GETSRC)) > >> ... > >> - have a definitive way to know when a client expects the source or > >> - know when a GET method originates from a DAV client > > > >Again: a DAV-client may want to do a GET on the output (for > testing), while > >a non-DAV client may want to see the source code. So *this* distinction > >doesn't make any sense at all. > > > There's nothing about GETSRC or Translate that would _prevent_ such a > configuration. If the administrator wants to support that, then he > can configure his server accordingly. My remark referred to "know when a GET method originates from a DAV client", no to "GETSRC" or the Translate header. From w3c-dist-auth-request@w3.org Thu Mar 7 10:08: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 KAA28731 for ; Thu, 7 Mar 2002 10:08:57 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA17415; Thu, 7 Mar 2002 10:07:32 -0500 (EST) Resent-Date: Thu, 7 Mar 2002 10:07:32 -0500 (EST) Resent-Message-Id: <200203071507.KAA17415@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 KAA17380 for ; Thu, 7 Mar 2002 10:06:54 -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 KAA01998 for ; Thu, 7 Mar 2002 10:06:53 -0500 Received: (qmail 9478 invoked by uid 0); 7 Mar 2002 15:06:18 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 7 Mar 2002 15:06:18 -0000 From: "Julian Reschke" To: "DAV" Date: Thu, 7 Mar 2002 16:06:16 +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: RFC2518 issue: format for multistatus when no property reported at all Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6054 X-Loop: w3c-dist-auth@w3.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 Consider a PROPFIND request like: I think this is clearly legal (by the DTD) and it can make sense if you're for instance just getting a list of member URIs for a collection. What format do we expect for the response body? 1) foobar I think this makes a lot of sense, but it breaks the DTD for the response element. 2) foobar HTTP/1.1 200 OK Conforms to the DTD, but isn't really logical (because in this case you may expect a 200 propstat element in the case where all queried properties are reported as 404 NOT FOUND as welll). 3) foobar HTTP/1.1 200 OK Conforms to the DTD as well, but isn't very logical. Why would the status element on response be required, if it is not when properties *are* reported. Proposal: allow format 1). Julian From w3c-dist-auth-request@w3.org Thu Mar 7 15:44:22 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 PAA22933 for ; Thu, 7 Mar 2002 15:44:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26721; Thu, 7 Mar 2002 15:41:50 -0500 (EST) Resent-Date: Thu, 7 Mar 2002 15:41:50 -0500 (EST) Resent-Message-Id: <200203072041.PAA26721@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 PAA26664 for ; Thu, 7 Mar 2002 15:41: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 PAA23623 for ; Thu, 7 Mar 2002 15:41: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; Thu, 07 Mar 2002 15:38:57 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 15:40:39 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B022@SUS-MA1IT01> From: "Clemm, Geoff" To: DAV Date: Thu, 7 Mar 2002 15:40:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: RFC2518 issue: format for multistatus when no property report ed at all Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6055 X-Loop: w3c-dist-auth@w3.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 vote for "not 1" (:-). I see no reason to break the DTD, with the potential for confusing clients/servers that are written to satisfy the DTD (as they should have been :-). Between 2 and 3, I personally prefer 3, because it is terser, but I think clients should be prepared to handle either. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, March 07, 2002 10:06 AM To: DAV Subject: RFC2518 issue: format for multistatus when no property reported at all Consider a PROPFIND request like: I think this is clearly legal (by the DTD) and it can make sense if you're for instance just getting a list of member URIs for a collection. What format do we expect for the response body? 1) foobar I think this makes a lot of sense, but it breaks the DTD for the response element. 2) foobar HTTP/1.1 200 OK Conforms to the DTD, but isn't really logical (because in this case you may expect a 200 propstat element in the case where all queried properties are reported as 404 NOT FOUND as welll). 3) foobar HTTP/1.1 200 OK Conforms to the DTD as well, but isn't very logical. Why would the status element on response be required, if it is not when properties *are* reported. Proposal: allow format 1). Julian From w3c-dist-auth-request@w3.org Fri Mar 8 06:08: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 GAA28573 for ; Fri, 8 Mar 2002 06:08:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA23181; Fri, 8 Mar 2002 06:04:13 -0500 (EST) Resent-Date: Fri, 8 Mar 2002 06:04:13 -0500 (EST) Resent-Message-Id: <200203081104.GAA23181@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 GAA23160 for ; Fri, 8 Mar 2002 06:03:43 -0500 (EST) Received: from waka.wakasoft.com (betwix.bsl.daynetwork.com [212.249.34.142] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA27091 for ; Fri, 8 Mar 2002 06:03:43 -0500 Received: (from fielding@localhost) by waka.wakasoft.com (8.11.0/8.11.0) id g28AwYC02159; Fri, 8 Mar 2002 02:58:34 -0800 Date: Fri, 8 Mar 2002 02:58:34 -0800 From: "Roy T. Fielding" To: CJ Holmes Cc: DAV Message-ID: <20020308025834.C1859@waka.wakasoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.20i Subject: Re: Translate (was RE: DAV-Enabled field (was RE: A case for GETSRC)) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6056 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > No, I don't agree that this is a problem. In most cases it is the > _desired_ effect because users generally only use DAV for messing > with their source, and they don't care about using DAV with the > output. But they _do_ want to use the same URLs for both editing > source and viewing output. If the administrator wants something > different he should be able to configure his server accordingly. You are saying that the protocol should have a one-to-one correspondence with the way that a client application presents information to the user. I am saying that the protocol must be unabiguous and compatible with HTTP/1.1, but that doesn't stop the client from presenting it to the user as if they were the same resource. The only difference is the URL, which is something an authoring client can and will present to the user in a way that is meaningful to that user. DAV is the access mechanism, not the user interface. ....Roy From w3c-dist-auth-request@w3.org Fri Mar 8 12:04: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 MAA17108 for ; Fri, 8 Mar 2002 12:04:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA08668; Fri, 8 Mar 2002 08:41:33 -0500 (EST) Resent-Date: Fri, 8 Mar 2002 08:41:33 -0500 (EST) Resent-Message-Id: <200203081341.IAA08668@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 IAA08408 for ; Fri, 8 Mar 2002 08:40:46 -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 IAA15054 for ; Fri, 8 Mar 2002 08:40:45 -0500 Received: (qmail 17008 invoked by uid 0); 8 Mar 2002 13:40:14 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 8 Mar 2002 13:40:14 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "DAV" Date: Fri, 8 Mar 2002 14:40:13 +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: <3906C56A7BD1F54593344C05BD1374B103F8B022@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: RFC2518 issue: format for multistatus when no property report ed at all Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6057 X-Loop: w3c-dist-auth@w3.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 don't like 3), but I can live with it. I think the "proper" solution would be to allow 1) in rfc2518++. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, March 07, 2002 9:41 PM > To: DAV > Subject: RE: RFC2518 issue: format for multistatus when no property > report ed at all > > > I vote for "not 1" (:-). I see no reason to break the DTD, with the > potential > for confusing clients/servers that are written to satisfy the DTD (as they > should > have been :-). Between 2 and 3, I personally prefer 3, because it is > terser, > but I think clients should be prepared to handle either. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, March 07, 2002 10:06 AM > To: DAV > Subject: RFC2518 issue: format for multistatus when no property reported > at all > > > Consider a PROPFIND request like: > > > > I think this is clearly legal (by the DTD) and it can make sense if you're > for instance just getting a list of member URIs for a collection. > > What format do we expect for the response body? > > 1) > > > > foobar > > > > > I think this makes a lot of sense, but it breaks the DTD for the response > element. > > > 2) > > > > foobar > > > HTTP/1.1 200 OK > > > > > Conforms to the DTD, but isn't really logical (because in this > case you may > expect a 200 propstat element in the case where all queried properties are > reported as 404 NOT FOUND as welll). > > > 3) > > > > foobar > HTTP/1.1 200 OK > > > > Conforms to the DTD as well, but isn't very logical. Why would the status > element on response be required, if it is not when properties *are* > reported. > > > Proposal: > > allow format 1). > > Julian > > > From w3c-dist-auth-request@w3.org Fri Mar 8 13:59: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 NAA25159 for ; Fri, 8 Mar 2002 13:59:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA21070; Fri, 8 Mar 2002 13:57:44 -0500 (EST) Resent-Date: Fri, 8 Mar 2002 13:57:44 -0500 (EST) Resent-Message-Id: <200203081857.NAA21070@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 NAA20819 for ; Fri, 8 Mar 2002 13:57:03 -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 NAA28534 for ; Fri, 8 Mar 2002 13:57:03 -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 KAA22075; Fri, 8 Mar 2002 10:57:02 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Cc: Date: Fri, 8 Mar 2002 10:57:16 -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: RFC 3253 - Versioning Extensions to WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6058 X-Loop: w3c-dist-auth@w3.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 DeltaV protocol specification was released as an RFC today! RFC 3253 is "Versioning Extensions to WebDAV", which extends RFC 2518 with capabilities for versioning and configuration management. RFC 3253 is a Proposed Standard, meaning it has resolved known technical tradeoffs, and is considered a stable base for widespread implementations. Major congratulations are due to Geoff Clemm, Jim Amsden, Tim Ellison, Chris Kaler, and the members of the DeltaV Design Team, and the DeltaV Working Group, for a job well done after 3.5 years of very hard work. http://www.ietf.org/rfc/rfc3253.txt Abstract This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning. - Jim From w3c-dist-auth-request@w3.org Mon Mar 11 08:12: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 IAA06928 for ; Mon, 11 Mar 2002 08:12:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA24004; Mon, 11 Mar 2002 08:10:15 -0500 (EST) Resent-Date: Mon, 11 Mar 2002 08:10:15 -0500 (EST) Resent-Message-Id: <200203111310.IAA24004@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 IAA23977 for ; Mon, 11 Mar 2002 08:10: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 IAA29547 for ; Mon, 11 Mar 2002 08:10:05 -0500 Received: (qmail 20444 invoked by uid 0); 11 Mar 2002 13:09:34 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp011-rz3) with SMTP; 11 Mar 2002 13:09:34 -0000 From: "Julian Reschke" To: "DAV" Date: Mon, 11 Mar 2002 14:09:33 +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: <20020308025834.C1859@waka.wakasoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: WebDAV Ordered Collections Protocol (draft-ietf-webdav-ordering-protocol) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6060 X-Loop: w3c-dist-auth@w3.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. We have implemented the WebDAV Ordered Collections Protocol both in a client and a server component and feel that it's complete and deserves to be revived (the current Internet Draft has expired, and it wasn't submitted as RFC). I haven taken the task to update it to a new version (03), which is available from our web site ([1]). The only changes made so far are: - Updated contact information for Jim Davis. - Specify charset when using text/xml media type. - Made sure artwork fits into 72 columns. - Removed "Public" header from OPTIONS example. We are not aware of any open issues in the old draft ([2] doesn't list any) and plan to submit this as an updated Internet Draft after the IETF meetings are finished. Feedback appreciated. Julian [1] [2] From w3c-dist-auth-request@w3.org Tue Mar 12 09:15:49 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22311 for ; Tue, 12 Mar 2002 09:15:49 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id C6B9B23371; Tue, 12 Mar 2002 05:14:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA07975; Fri, 8 Mar 2002 16:41:37 -0500 (EST) Resent-Date: Fri, 8 Mar 2002 16:41:37 -0500 (EST) Resent-Message-Id: <200203082141.QAA07975@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 QAA07333 for ; Fri, 8 Mar 2002 16:40:10 -0500 (EST) Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA05689 for ; Fri, 8 Mar 2002 14:47:05 -0500 Received: from hollywood.cinenet.net (hollywood.cinenet.net [198.147.76.75]) by tahoe.cinenet.net (8.11.6/8.11.6) with ESMTP id g28Jl5S16883; Fri, 8 Mar 2002 11:47:05 -0800 (PST) Received: from localhost (modulus@localhost) by hollywood.cinenet.net (SMI-8.6/) with ESMTP id LAA18462; Fri, 8 Mar 2002 11:47:00 -0800 X-Authentication-Warning: hollywood.cinenet.net: modulus owned process doing -bs Date: Fri, 8 Mar 2002 11:46:59 -0800 (PST) From: "Yaron Y. Goland" Reply-To: "Yaron Y. Goland" To: WebDAV Cc: Jim Whitehead In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: RFC 3253 - Versioning Extensions to WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6059 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Several years ago a graduate student from UCI had an idea; maybe we could make Tim Berners-Lee's original vision of a write-able web come true. He collected together a motley crew of academics and corporate mavericks and started to build a standard. More years later then any of us care to remember that graduate student's (now a professor at UCSC) original vision of a set of standards upon which to build a write-able web has finally come true. With RFC 2518 and RFC 3253 it is now possible to build rich, full featured, interoperable document management products. Of course there is more work to do. There always is. But the terms of engagement have changed, the standards are there, the foundation is built, now it's time to get on to the rest of the building. The number of people who had to put in hard hours to make WebDAV a reality is long and many of them are acknowledged in RFC 2518 and RFC 3253 but none of us would have been able to make these contributions if it hadn't been for the vision, persistence, generosity and level headedness of Jim Whitehead. So thank you Jim! Yaron On Fri, 8 Mar 2002, Jim Whitehead wrote: > > The DeltaV protocol specification was released as an RFC today! RFC 3253 is > "Versioning Extensions to WebDAV", which extends RFC 2518 with capabilities > for versioning and configuration management. RFC 3253 is a Proposed > Standard, meaning it has resolved known technical tradeoffs, and is > considered a stable base for widespread implementations. > > Major congratulations are due to Geoff Clemm, Jim Amsden, Tim Ellison, Chris > Kaler, and the members of the DeltaV Design Team, and the DeltaV Working > Group, for a job well done after 3.5 years of very hard work. > > http://www.ietf.org/rfc/rfc3253.txt > > Abstract > > This document specifies a set of methods, headers, and resource types > that define the WebDAV (Web Distributed Authoring and Versioning) > versioning extensions to the HTTP/1.1 protocol. WebDAV versioning > will minimize the complexity of clients that are capable of > interoperating with a variety of versioning repository managers, to > facilitate widespread deployment of applications capable of utilizing > the WebDAV Versioning services. WebDAV versioning includes automatic > versioning for versioning-unaware clients, version history > management, workspace management, baseline management, activity > management, and URL namespace versioning. > > - Jim > From w3c-dist-auth-request@w3.org Tue Mar 12 18:38:20 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12233 for ; Tue, 12 Mar 2002 18:38:19 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id AA94722BD7; Tue, 12 Mar 2002 18:35:25 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09545; Tue, 12 Mar 2002 16:42:08 -0500 (EST) Resent-Date: Tue, 12 Mar 2002 16:42:08 -0500 (EST) Resent-Message-Id: <200203122142.QAA09545@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 QAA09135 for ; Tue, 12 Mar 2002 16:41:07 -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 OAA01219 for ; Tue, 12 Mar 2002 14:38:16 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id LAA27258 for w3c-dist-auth@w3.org; Tue, 12 Mar 2002 11:41:18 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 12 Mar 2002 11:41:18 -0800 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20020312114118.H26839@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i X-URL: http://www.lyra.org/greg/ Subject: Speaking at conference (Zurich, March 21, 22) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6061 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Next week, I'll be speaking about WebDAV and Subversion at the Open Source Content Management Systems Conference (http://conference.wyona.org/). The conference is in Zurich, Switzerland, and is Thursday (the 21st) and Friday, and I'll be there through the weekend. I'd like to invite others that are nearby to the conference. If you can't attend the conference, but still may want to have a "WebDAV / DeltaV / Subversion get-together", then just drop me a note. We might be able to arrange something for Friday evening. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Mar 15 12:15:44 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04875 for ; Fri, 15 Mar 2002 12:15:44 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 2724522BCC; Fri, 15 Mar 2002 12:15:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA25551; Fri, 15 Mar 2002 12:14:46 -0500 (EST) Resent-Date: Fri, 15 Mar 2002 12:14:46 -0500 (EST) Resent-Message-Id: <200203151714.MAA25551@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 MAA25527 for ; Fri, 15 Mar 2002 12:14:37 -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 MAA27790 for ; Fri, 15 Mar 2002 12:14:37 -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 JAA09888 for ; Fri, 15 Mar 2002 09:14:32 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 15 Mar 2002 09:14:45 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FW: WebDAV Matrix Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6062 X-Loop: w3c-dist-auth@w3.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, but you should make sure you also cc him on any responses. - Jim -----Original Message----- From: Frank Lowney [mailto:flowney@mail.gcsu.edu] Sent: Wednesday, March 13, 2002 4:58 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAB Matrix I was looking around the WebDAV site (www.webdav.org) for information that guide me and my team to a strategy for deploying WebDAV among our user base. I did not find what I was looking for so I'm approaching this list w/ my questions. If these questions should go elsewhere, please let me have an address. Server environment: WebSTAR V on MacOS X Server 10.1.3 User base: A group of independent knowledge workers (university faculty) with a heterogeneous array of tools and a highly variable propensity to acquire new tools (every possible combination and permutation of: some will, some won't, some can, some can't). One of the things that I was hoping to find was a matrix of what applications could be used on what platforms with what limitations. For example, I have heard that Microsoft Office supports WebDAV but it's unclear as to whether that statement refers to: Mac: Office 2001 or Office X Win: Office 2000 or Office XP ...and to what extent that support goes and how exactly one uses these apps to work with a WebDAV server. The second question I was looking for guidance on has to do with how I might use WebDAV access with a fairly large group (50 or so) of editors who all work on various parts of a single web site. The goal is to give them access that is easier for them than FTP yet keeps them apart (professor A cannot see or write to professor B's area and vice-versa). Thanks in advance for any light that you may be able to shed on this. -- ===================================================================== Dr. Frank Lowney flowney@mail.gcsu.edu Director, Electronic Instructional Services, a unit of the Office of Information and Instructional Technology, Professional Pages: http://www.gcsu.edu/oiit/eis/ Personal Pages: http://www.faculty.de.gcsu.edu/~flowney Voice: (478) 445-5260 ===================================================================== We don't make instruction effective, we make effective instruction more accessible. From w3c-dist-auth-request@w3.org Fri Mar 15 14:18:26 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07522 for ; Fri, 15 Mar 2002 14:18:25 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 4387822C03; Fri, 15 Mar 2002 14:18:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA09436; Fri, 15 Mar 2002 14:18:14 -0500 (EST) Resent-Date: Fri, 15 Mar 2002 14:18:14 -0500 (EST) Resent-Message-Id: <200203151918.OAA09436@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 OAA09393 for ; Fri, 15 Mar 2002 14:17:51 -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 OAA18959 for ; Fri, 15 Mar 2002 14:17:51 -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 g2FJHnQ24290 for ; Fri, 15 Mar 2002 11:17:49 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 15 Mar 2002 11:17:48 -0800 Received: from luthj1 (luthj1.apple.com [17.201.21.213]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g2FJHmX07330; Fri, 15 Mar 2002 11:17:48 -0800 (PST) Date: Fri, 15 Mar 2002 11:17:47 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: flowney@mail.gcsu.edu To: w3c-dist-auth@w3.org From: Jim Luther Content-Transfer-Encoding: 7bit Message-Id: <55EF3DE2-3849-11D6-B422-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.481) Subject: Mac OS X WebDAV file system Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6065 X-Loop: w3c-dist-auth@w3.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 Frank, Mac OS X includes a file system for WebDAV that lets you mount a WebDAV enabled folder as a file system volume. Any application running under Mac OS X, except for those running in the Classic Mac OS 9 environment, can directly access documents on a WebDAV server through the file system. Native Mac OS 9 does not include a file system for WebDAV. Microsoft Office X can access WebDAV volumes because its components are Mac OS X applications. Microsoft Office 2001 components cannot access WebDAV volumes directly because they run under the Classic Mac OS 9 environment -- users of Microsoft Office 2001 would have to use the Mac OS X Finder to copy the files to a local volume (which Classic applications can access) to access files on a WebDAV volume. I don't know the Mac OS X Server product, so I can't help you with questions related to it. Jim Luther Apple Computer, Inc. > On Friday, March 15, 2002, at 09:14 AM, Jim Whitehead wrote: > > Accidentally caught by the spam filter. I have added > > to the accept2 list, but you should make sure you also cc him on any > responses. > > - Jim > > -----Original Message----- > From: Frank Lowney [mailto:flowney@mail.gcsu.edu] > Sent: Wednesday, March 13, 2002 4:58 PM > To: w3c-dist-auth@w3.org > Subject: [Moderator Action] WebDAB Matrix > > > I was looking around the WebDAV site (www.webdav.org) for information > that guide me and my team to a strategy for deploying WebDAV among > our user base. I did not find what I was looking for so I'm > approaching this list w/ my questions. If these questions should go > elsewhere, please let me have an address. > > Server environment: WebSTAR V on MacOS X Server 10.1.3 > > User base: A group of independent knowledge workers (university > faculty) with a heterogeneous array of tools and a highly variable > propensity to acquire new tools (every possible combination and > permutation of: some will, some won't, some can, some can't). > > One of the things that I was hoping to find was a matrix of what > applications could be used on what platforms with what limitations. > For example, I have heard that Microsoft Office supports WebDAV but > it's unclear as to whether that statement refers to: > > Mac: Office 2001 or Office X > Win: Office 2000 or Office XP > > ...and to what extent that support goes and how exactly one uses > these apps to work with a WebDAV server. > > The second question I was looking for guidance on has to do with how > I might use WebDAV access with a fairly large group (50 or so) of > editors who all work on various parts of a single web site. The goal > is to give them access that is easier for them than FTP yet keeps > them apart (professor A cannot see or write to professor B's area and > vice-versa). > > Thanks in advance for any light that you may be able to shed on this. > -- > ===================================================================== > Dr. Frank Lowney flowney@mail.gcsu.edu > Director, Electronic Instructional Services, a unit of the > Office of Information and Instructional Technology, > Professional Pages: http://www.gcsu.edu/oiit/eis/ > Personal Pages: http://www.faculty.de.gcsu.edu/~flowney > Voice: (478) 445-5260 > ===================================================================== > We don't make instruction effective, we make effective instruction > more accessible. > From w3c-dist-auth-request@w3.org Fri Mar 15 14:29:00 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07883 for ; Fri, 15 Mar 2002 14:29:00 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 095D922BEE; Fri, 15 Mar 2002 14:29:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10255; Fri, 15 Mar 2002 14:28:54 -0500 (EST) Resent-Date: Fri, 15 Mar 2002 14:28:54 -0500 (EST) Resent-Message-Id: <200203151928.OAA10255@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 OAA10217 for ; Fri, 15 Mar 2002 14:28:32 -0500 (EST) Received: from smtp.zope.com ([63.100.190.95]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA21249 for ; Fri, 15 Mar 2002 14:28:32 -0500 Received: from suxlap (suxlap.digicool.com [192.168.23.62]) (authenticated) by smtp.zope.com (8.11.6/8.11.2) with ESMTP id g2FJS8f32122 for ; Fri, 15 Mar 2002 14:28:08 -0500 Message-ID: <042501c1cc57$30f70280$3e17a8c0@suxlap> Reply-To: "Andreas Jung" From: "Andreas Jung" To: Date: Fri, 15 Mar 2002 14:25:27 -0500 Organization: Zope Corporation 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 X-MailScanner: Found to be clean Subject: Microsoft webfolders WebDAV incompatibility issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6066 X-Loop: w3c-dist-auth@w3.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 Zope offers an almost complete and compliant WebDAV implementation. However we run into some compatiblity related problems when we use Zope through webfolders under Windows (XP) and Microsoft problem. It is a very common problem that Office complains that a file is read-only when trying to save the file. We figured out that Microsofts WebDAV implementation requires an ETAG header to work correctly. However this does not seem to work on all Windows installations. Reverse engineering Microsofts behaviour on the protocol level is nerving. Does anyone has similiar problems or any additional thoughts and tips on that issue? Andreas Jung From w3c-dist-auth-request@w3.org Fri Mar 15 15:37:45 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09636 for ; Fri, 15 Mar 2002 15:37:45 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA00516; Fri, 15 Mar 2002 15:37:33 -0500 Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26980; Fri, 15 Mar 2002 12:31:10 -0500 (EST) Resent-Date: Fri, 15 Mar 2002 12:31:10 -0500 (EST) Resent-Message-Id: <200203151731.MAA26980@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 MAA26889 for ; Fri, 15 Mar 2002 12:30:21 -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 MAA31362 for ; Fri, 15 Mar 2002 12:30:20 -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 JAA17404; Fri, 15 Mar 2002 09:30:16 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" , Date: Fri, 15 Mar 2002 09:30: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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: WebDAV Matrix Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6064 X-Loop: w3c-dist-auth@w3.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 > One of the things that I was hoping to find was a matrix of what > applications could be used on what platforms with what limitations. > For example, I have heard that Microsoft Office supports WebDAV but > it's unclear as to whether that statement refers to: > > Mac: Office 2001 or Office X > Win: Office 2000 or Office XP Microsoft Office 2000 and XP support WebDAV on Windows platforms. This is accessed via a feature called "Web Folders". An explanation of how to set up and use Web Folders from the Windows file system can be found at: http://www.mydocsonline.com/info_webfolders.html From Office, once a Web Folder is created, you access it via the File ... Open dialog box (a Web Folders icon is in the bottom left of the dialog box). Mac versions of Office do not support WebDAV, as far as I know. The Mac version of Office is a distinct code base from the Windows version. Mac OS X supports mapping a WebDAV server to a drive -- I can't find any documentation on the net for how to do this. Office on the Mac can read/write to a DAV-mapped drive. A fairly complete list of DAV-supporting applications can be found at: http://www.ics.uci.edu/pub/ietf/webdav/ (About 1/2 way down the page). Adobe DAV-supporting applications (Photoshop, Illustrator 10, Acrobat 5, InDesign 2, others...) support DAV evenly across the Mac and Windows platform. > ...and to what extent that support goes and how exactly one uses > these apps to work with a WebDAV server. This information would be great. We're a volunteer organization here, so if you do develop this kind of information, we would gladly host it on WebDAV.org. > The second question I was looking for guidance on has to do with how > I might use WebDAV access with a fairly large group (50 or so) of > editors who all work on various parts of a single web site. The goal > is to give them access that is easier for them than FTP yet keeps > them apart (professor A cannot see or write to professor B's area and > vice-versa). You would map the information to spaces served by a DAV server, and then set the local permissions in the DAV server such that only the appropriate authors had access to specific areas (i.e., except for the being served by a DAV server, the answer is much the same as for a local file system). - Jim From w3c-dist-auth-request@w3.org Fri Mar 15 16:26:34 2002 Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09635 for ; Fri, 15 Mar 2002 15:37:45 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA00365; Fri, 15 Mar 2002 15:37:00 -0500 Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA26925; Fri, 15 Mar 2002 12:30:44 -0500 (EST) Resent-Date: Fri, 15 Mar 2002 12:30:44 -0500 (EST) Resent-Message-Id: <200203151730.MAA26925@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 MAA26878 for ; Fri, 15 Mar 2002 12:30:19 -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 MAA31356 for ; Fri, 15 Mar 2002 12:30:19 -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 JAA17397 for ; Fri, 15 Mar 2002 09:30:15 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Fri, 15 Mar 2002 09:30:28 -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: FW: WebDAV Help!!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6063 X-Loop: w3c-dist-auth@w3.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. - Jim -----Original Message----- From: Blaha, Robert T [mailto:Robert.Blaha@unisys.com] Sent: Thursday, March 14, 2002 5:28 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV Help!!! What makes a WebDAV server a WebDAV Server??? Is there some software required on the server, or a setting selection that needs to be enabled? I am currently trying to get share on a Windows 2000 Server (running IIS 5.?) to function as a WebDAV Server (for Intranet use). I am using Adobe GoLive 5.0 as my authoring tool but to no avail I can not get GoLive's WebDAV browser to recognize the share. It connects but will not see any files. I have tried to connect to the server and "synchronize the files from a local HD, but files and Folders (Directories) can not be created. I tried it with FrontPage 2000 and it worked, but unfortunately the Site was created with GoLive and we would like to continue to use it. I had the server tech give full rights to us and remove the FrontPage extensions from the share but to no avail... Please Help!! Thanks for your time, Bob Blaha From w3c-dist-auth-request@w3.org Mon Mar 18 13:37:49 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14723 for ; Mon, 18 Mar 2002 13:37:49 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 6D37722CAA; Mon, 18 Mar 2002 13:37:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03812; Mon, 18 Mar 2002 13:37:12 -0500 (EST) Resent-Date: Mon, 18 Mar 2002 13:37:12 -0500 (EST) Resent-Message-Id: <200203181837.NAA03812@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 NAA03618 for ; Mon, 18 Mar 2002 13:36:45 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA05485 for ; Mon, 18 Mar 2002 13:36:45 -0500 Received: from 10.196.0.11 by mail.4d.com; Mon, 18 Mar 2002 10:36:31 -0800 Mime-Version: 1.0 X-Sender: aci-us\CJ Holmes\cholmes@imap.4d.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 18 Mar 2002 10:36:03 -0800 To: DAV From: CJ Holmes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: RE: WebDAV Matrix Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6067 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: >Mac OS X supports mapping a WebDAV server to a drive -- I can't find any >documentation on the net for how to do this. Office on the Mac can >read/write to a DAV-mapped drive. From the Finder, use the "Go" menu and select "Connect to Server..." (or just hit apple-K). Enter the URL that you want to connect to. eg: http://www.my.org/naturalSciences/ You will be prompted for your username and password. The finder-based DAV is very cool because it lets you use your DAV server like a disk. But it doesn't support locking, last time I checked. But Goliath does, and works on MacOS X. > > The second question I was looking for guidance on has to do with how >> I might use WebDAV access with a fairly large group (50 or so) of >> editors who all work on various parts of a single web site. The goal >> is to give them access that is easier for them than FTP yet keeps >> them apart (professor A cannot see or write to professor B's area and > > vice-versa). That is really dependent on your server software, but you control DAV access just like you control any other kind of access to your web server. cjh -- From w3c-dist-auth-request@w3.org Mon Mar 18 14:56:03 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17681 for ; Mon, 18 Mar 2002 14:56:03 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id CD2DE22C2F; Mon, 18 Mar 2002 14:20:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10559; Mon, 18 Mar 2002 14:20:00 -0500 (EST) Resent-Date: Mon, 18 Mar 2002 14:20:00 -0500 (EST) Resent-Message-Id: <200203181920.OAA10559@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 OAA10502 for ; Mon, 18 Mar 2002 14:19:37 -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 OAA11174 for ; Mon, 18 Mar 2002 14:19:38 -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 g2IJJXQ16811 for ; Mon, 18 Mar 2002 11:19:34 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 18 Mar 2002 11:19:33 -0800 Received: from luthj1 (luthj1.apple.com [17.201.21.213]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g2IJJSb17338; Mon, 18 Mar 2002 11:19:29 -0800 (PST) Date: Mon, 18 Mar 2002 11:19:28 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: DAV To: CJ Holmes From: Jim Luther In-Reply-To: Message-Id: <111BD10E-3AA5-11D6-95AA-0003934B6A22@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Subject: Re: WebDAV Matrix Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6068 X-Loop: w3c-dist-auth@w3.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, March 18, 2002, at 10:36 AM, CJ Holmes wrote: > From the Finder, use the "Go" menu and select "Connect to Server..." > (or just hit apple-K). Enter the URL that you want to connect to. eg: > http://www.my.org/naturalSciences/ And if the URL doesn't go to a WevDAV-enabled server directory (i.e., it's an URL to some random web page), the mount will fail with an error 19 (no device... the best error code we could map it to). > You will be prompted for your username and password. You'll be prompted only if the WevDAV-enabled server directory requires authentication. For example, requires no authentication. > The finder-based DAV is very cool because it lets you use your DAV > server like a disk. But it doesn't support locking, last time I > checked. But Goliath does, and works on MacOS X. The Mac OS X WebDAV file system does use the LOCK method. DAV class 1 WebDAV servers are mounted as read-only volumes because the LOCK method isn't required for class 1 resources. DAV class 2 WebDAV servers are mounted as read-write volumes. On these servers, when a file (resource) is opened with write access, the WebDAV file system uses the LOCK method to acquire a lock on the file being opened with a timeout of 10 minutes. If the lock cannot be acquired, then the file cannot be opened with write access. The lock is refreshed every 5 minutes until the file is closed. When the file is closed, the UNLOCK method is used to unlock the file. The WebDAV file system does not acquire a lock on files opened with read-only access. Jim Luther Apple Computer, Inc. From w3c-dist-auth-request@w3.org Mon Mar 18 16:15:03 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20469 for ; Mon, 18 Mar 2002 16:15:03 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 9E25022C72; Mon, 18 Mar 2002 16:15:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21193; Mon, 18 Mar 2002 16:15:01 -0500 (EST) Resent-Date: Mon, 18 Mar 2002 16:15:01 -0500 (EST) Resent-Message-Id: <200203182115.QAA21193@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 QAA21147 for ; Mon, 18 Mar 2002 16:14:51 -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 QAA30226 for ; Mon, 18 Mar 2002 16:14:51 -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 NAA04265 for ; Mon, 18 Mar 2002 13:14:46 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 18 Mar 2002 13:14:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C1CE7E.E6E234B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: Help me please with idisk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6069 X-Loop: w3c-dist-auth@w3.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_000A_01C1CE7E.E6E234B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Help me please with idiskAccidentally caught by the spam filter. - Jim -----Original Message----- From: Roberto Piacenza [mailto:cenza@mac.com] Sent: Saturday, March 16, 2002 4:45 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Help me please with idisk Hello: i wish you can help me, i need to connect to my idisk (macintosh) from adobe golive, i connect via webdav, i can see all the files in the webdav side, but when i want to upload modified files i get a lot of errors, and hothing is uploaded, apple doesn´t help me, adobe doesn´t help me, and you? I need help, i wish you can, thank you, Roberto Piacenza ------=_NextPart_000_000A_01C1CE7E.E6E234B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Help me please with idisk
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Roberto Piacenza=20 [mailto:cenza@mac.com]
Sent: Saturday, March 16, 2002 4:45=20 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action] Help=20 me please with idisk

Hello: i = wish you=20 can help me, i need to connect to my idisk (macintosh) from adobe = golive, i=20 connect via webdav, i can see all the files in the webdav side, but when = i want=20 to upload modified files i get a lot of errors, and hothing is uploaded, = apple=20 doesn=B4t help me, adobe doesn=B4t help me, and you?
I need help, i = wish you can,=20 thank you, Roberto Piacenza ------=_NextPart_000_000A_01C1CE7E.E6E234B0-- From w3c-dist-auth-request@w3.org Mon Mar 18 16:35:29 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21256 for ; Mon, 18 Mar 2002 16:35:28 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id A93A822CE5; Mon, 18 Mar 2002 16:35:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA23094; Mon, 18 Mar 2002 16:35:24 -0500 (EST) Resent-Date: Mon, 18 Mar 2002 16:35:24 -0500 (EST) Resent-Message-Id: <200203182135.QAA23094@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 QAA22967 for ; Mon, 18 Mar 2002 16:35:05 -0500 (EST) Received: from mail.4d.com ([216.33.0.197]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA00920 for ; Mon, 18 Mar 2002 16:35:04 -0500 Received: from mailbox.4d.com [216.33.0.219] by mail.4d.com; Mon, 18 Mar 2002 13:35:07 -0800 Received: by SRV-EXCHANGE with Internet Mail Service (5.5.2448.0) id ; Mon, 18 Mar 2002 13:35:02 -0800 Message-ID: From: Matthieu Chevrier To: DAV Date: Mon, 18 Mar 2002 13:34:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Help me please with idisk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6070 X-Loop: w3c-dist-auth@w3.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 first implementations of (WebDAV+iDisk) were using Basic authentication. Some users expressed security concerns about exposing their passwords so Apple must have switched to MD5-Digest (with OSX 10.1.1) If it is indeed the case and that GoLive does not support MD5 yet (GoLive 5 didn't as far as I know) then you just can't access your iDisk using GoLive. Matthieu. From w3c-dist-auth-request@w3.org Mon Mar 18 17:33:20 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23321 for ; Mon, 18 Mar 2002 17:33:19 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id E653A22CAD; Mon, 18 Mar 2002 17:33:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA03039; Mon, 18 Mar 2002 17:33:14 -0500 (EST) Resent-Date: Mon, 18 Mar 2002 17:33:14 -0500 (EST) Resent-Message-Id: <200203182233.RAA03039@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 RAA02817 for ; Mon, 18 Mar 2002 17:32:53 -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 RAA12149 for ; Mon, 18 Mar 2002 17:32:53 -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 g2IMWqa15804 for ; Mon, 18 Mar 2002 14:32:52 -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, 18 Mar 2002 14:32:52 -0800 Received: from luthj1 (luthj1.apple.com [17.201.21.213]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g2IMWpb04687 for ; Mon, 18 Mar 2002 14:32:51 -0800 (PST) Date: Mon, 18 Mar 2002 14:32:51 -0800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Jim Luther To: DAV In-Reply-To: Message-Id: <150818DC-3AC0-11D6-A167-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id RAA02817 Subject: Re: Help me please with idisk Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6071 X-Loop: w3c-dist-auth@w3.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 >> From: Roberto Piacenza [mailto:cenza@mac.com] >> Sent: Saturday, March 16, 2002 4:45 PM >> To: w3c-dist-auth@w3.org >> Subject: [Moderator Action] Help me please with idisk >> >> Hello: i wish you can help me, i need to connect to my idisk >> (macintosh) from adobe golive, i connect via webdav, i can see all the >> files in the webdav side, but when i want to upload modified files i >> get a lot of errors, and hothing is uploaded, apple doesn´t help me, >> adobe doesn´t help me, and you? >> I need help, i wish you can, thank you, Roberto Piacenza On Monday, March 18, 2002, at 01:34 PM, Matthieu Chevrier wrote: > The first implementations of (WebDAV+iDisk) were using Basic > authentication. > Some users expressed security concerns about exposing their passwords so > Apple must have switched to MD5-Digest (with OSX 10.1.1) > > If it is indeed the case and that GoLive does not support MD5 yet > (GoLive 5 > didn't as far as I know) then you just can't access your iDisk using > GoLive. Apple's iDisk WebDAV servers currently challenge with both a Basic access WWW-Authenticate header and a Digest access WWW-Authenticate header and the server will accept either Basic or Digest authorizations from WebDAV clients. The servers were switched to allow Digest in addition to Basic at the same time Digest support was added to Mac OS X WebDAV file system (Mac OS X v10.1.1). So, authentication isn't the problem. The only thing that is lost between upload to the iDisk server from the Mac OS X file system and downloading with another client are the AppleDouble file which store Macintosh specific Finder metadata and the resource forks of files -- the AppleDouble files are hidden from non-Mac OS X file system clients. Jim Luther Apple Computer, Inc. From w3c-dist-auth-request@w3.org Tue Mar 19 08:13:45 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21000 for ; Tue, 19 Mar 2002 08:13:45 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id C8EAE22C29; Tue, 19 Mar 2002 08:13:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA08548; Tue, 19 Mar 2002 08:13:41 -0500 (EST) Resent-Date: Tue, 19 Mar 2002 08:13:41 -0500 (EST) Resent-Message-Id: <200203191313.IAA08548@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 IAA08493 for ; Tue, 19 Mar 2002 08:13:10 -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 IAA13625; Tue, 19 Mar 2002 08:13:09 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id FAA07211; Tue, 19 Mar 2002 05:16:39 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 19 Mar 2002 05:16:39 -0800 From: Greg Stein To: Julian Reschke , "Sohn, Matthias" Cc: ietf-dav-versioning@w3.org, w3c-dist-auth@w3.org Message-ID: <20020319051639.E6628@lyra.org> Mail-Followup-To: Julian Reschke , "Sohn, Matthias" , ietf-dav-versioning@w3.org, 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 julian.reschke@greenbytes.de on Tue, Mar 19, 2002 at 10:58:32AM +0100 X-URL: http://www.lyra.org/greg/ Subject: Re: how to specify extension features in response to OPTIONS request Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6072 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tue, Mar 19, 2002 at 10:58:32AM +0100, Julian Reschke wrote: > > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Sohn, Matthias >... > > is it possible to specify extension features (that are not defined in the > > DeltaV spec) in the response to a OPTIONS request ? > > It's possible, but I would strongly recommend not to do that. > > If you need a non-intrusive way to signal server extensions, use a custom > live property. There was some amount of consensus a while back on the DAV WG list that the DAV: header should allow Coded-URLs in it. mod_dav took this approach, so an OPTIONS response looks like: HTTP/1.1 200 OK Date: Tue, 19 Mar 2002 13:10:17 GMT Server: Apache/1.3.19 (Unix) DAV/1.0.2 Content-Length: 0 MS-Author-Via: DAV Allow: OPTIONS, GET, HEAD, POST, DELETE, TRACE, PROPFIND, PROPPATCH, COPY, MOVE, LOCK, UNLOCK DAV: 1,2, Connection: close Content-Type: text/plain Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Mar 20 07:23:13 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28494 for ; Wed, 20 Mar 2002 07:23:13 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 7ADC422CE0; Wed, 20 Mar 2002 07:22:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA08761; Wed, 20 Mar 2002 05:20:24 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 05:20:24 -0500 (EST) Resent-Message-Id: <200203201020.FAA08761@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 EAA02946 for ; Wed, 20 Mar 2002 04:42:49 -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 EAA16602; Wed, 20 Mar 2002 04:13:13 -0500 Received: from lisa [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R); Wed, 20 Mar 2002 10:12:26 +0100 From: "Julian Reschke" To: "Lisa Dusseault" , "'Greg Stein'" , "'Sohn, Matthias'" Cc: , Date: Wed, 20 Mar 2002 10:12:26 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <002e01c1cfb6$4e039660$30bf3fa6@moose> X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de Subject: RE: how to specify extension features in response to OPTIONS request Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6073 X-Loop: w3c-dist-auth@w3.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: Lisa Dusseault [mailto:ldusseault@xythos.com] > Sent: Wednesday, March 20, 2002 3:24 AM > To: 'Greg Stein'; 'Julian Reschke'; 'Sohn, Matthias' > Cc: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org > Subject: RE: how to specify extension features in response to OPTIONS > request > > > > There was some amount of consensus a while back on the DAV WG > > list that the > > DAV: header should allow Coded-URLs in it. mod_dav took this > > approach, so an > > OPTIONS response looks like: > > If Greg's approach is taken to avoid conflicts, then I see no > strong reason > to prefer live properties over OPTIONS header values in the general case. ...other that in this case this way to extend the DASL header must be documented somewhere...? > However, if the feature is one which relates only to some resources (e.g. > all collections support the feature, or all resources in the > directory foo, > etc) then it might be helpful to advertise support for the feature only on > those resources, using a live property as suggested. > > OPTIONS * still seems to be the most appropriate place to marshall > server-wide features, with the conflict-avoidance caveats already > mentioned. How can this be the appropriate place if RFC2518 doesn't document how to do that? From w3c-dist-auth-request@w3.org Wed Mar 20 16:45:38 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16004 for ; Wed, 20 Mar 2002 16:45:37 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 3EFF922D94; Wed, 20 Mar 2002 16:42:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15787; Wed, 20 Mar 2002 16:40:39 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 16:40:39 -0500 (EST) Resent-Message-Id: <200203202140.QAA15787@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 QAA15488 for ; Wed, 20 Mar 2002 16:39:58 -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 QAA15462 for ; Wed, 20 Mar 2002 16:11:11 -0500 Received: from LIILMTLSFE02.mailtask.com ([208.203.59.43]) by LIILMTLSSM01.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 15:10:39 -0600 Received: from moose ([166.63.189.216]) by LIILMTLSFE02.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 15:10:40 -0600 From: "Lisa Dusseault" To: Date: Wed, 20 Mar 2002 13:12:11 -0800 Message-ID: <002c01c1d053$e7cded20$ecba3fa6@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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 20 Mar 2002 21:10:40.0383 (UTC) FILETIME=[B06C38F0:01C1D053] Subject: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6074 X-Loop: w3c-dist-auth@w3.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 been watching the OPES (Open Pluggable Edge Services) WG work and thus I've developed some concerns about how edge services interoperate with authoring clients. Edge services in the Web are services which may review or modify content at the "edge" of the Web, that is, between the origin content server and the end-consumer browser. For example, an edge service might be a company's HTTP proxy, which could perform virus scanning and reject virus payloads. Another simple example is a translation service -- in this case, the edge service might be addressed explicitly by the client in order to have the content transformed. Transparent edge services do not interoperate easily with authoring applications that rely on HTTP GET to retrieve source. This obviously applies to WebDAV. It is time for us to solve the problem of retrieving source, so that we can give our input to OPES as it develops. Some initial thoughts about this: 1. It seems unreasonable for existing WebDAV clients to wait for various OPES standards to be defined and then implement those protocols in order to request edge services *not* to be performed. Either edge services should not transform data without explicitly being asked (and that is being considered in the WG) or authoring clients should add information to requests now to signal that edge services aren't desired. Note that neither is secure because nothing stops rogue edge services from performing transformation anyway. 2. The situation could be made easier if all WebDAV clients were able to include a header in GET requests indicating that the request is being made by an authoring client, not a browsing client. I suggest a header rather than a method, because a new method will not be supported for much longer, and won't interoperate with non-WebDAV servers. 3. The source property is no help in this situation. Doing a PROPFIND can get you the source property, but then a GET to the URL in that property may be subject to the same edge service transformations as the original URL. 4. End-to-end encryption and/or signatures are the ultimate way to stop edge services from transforming data. Perhaps the spec coudl use a recommendation that WebDAV servers SHOULD support TLS, and that WebDAV clients SHOULD attempt to use TLS, even for content that is also available unencrypted. However, there are some unsolved issues here. How does the client discover that the content available over TLS is the same as the content available over unsecured HTTP, in cases where the content doesn't need to be secured by TLS for ordinary browsers? Note that it's equally possible for the server to host *different* content on ports 80 and 443, so the client must be able to differentiate the two cases. I do not have strong preferences but I have many concerns. I'd like to see solid proposals with discussions of all the known issues, and lots of feedback on what proposals would be *acceptable*. This may be a situation where a large part of the community may have to accept a proposal that is not their preferred proposal if it is at least acceptable. Lisa From w3c-dist-auth-request@w3.org Wed Mar 20 16:48:15 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16053 for ; Wed, 20 Mar 2002 16:48:15 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 6D1FF22E60; Wed, 20 Mar 2002 16:42:36 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA16051; Wed, 20 Mar 2002 16:41:05 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 16:41:05 -0500 (EST) Resent-Message-Id: <200203202141.QAA16051@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 QAA15490 for ; Wed, 20 Mar 2002 16:39:59 -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 QAA15454 for ; Wed, 20 Mar 2002 16:11:08 -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 NAA19712 for ; Wed, 20 Mar 2002 13:11:05 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 20 Mar 2002 13:11:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id QAA15490 Subject: FW: [Moderator Action] WebDAV WG minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6075 X-Loop: w3c-dist-auth@w3.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. I have added to the accept2 list. - Jim -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Tuesday, March 19, 2002 5:47 PM To: minutes@ietf.org; w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV WG minutes Minutes from WebDAV WG meeting March 19, 2002 53rd IETF, Minneapolis Reported by Larry Masinter, Adobe Chair present: Lisa Dusseault, Xythos Status of Various Efforts ------------------------- DeltaV: The DeltaV working group is closed, however issues are still being discussed actively on the working group mailing list. No interop events are planned as yet. Q: Any clients for DeltaV? TeamStream (Xythos web file client) is a very limited client. Might assume that server vendors have clients. SubVersion has a client, but will only work with SubVersion for a while. Interop Plans: WebDAV to Draft Standard requires demonstration of interoperability of various features between independent implementations. First interop was last August, another last fall, want to start again this spring. Suggestion from Brotsky: schedule rolling, round-robin, server interops, e.g., server-client pair have dates for focus on interop issues. Match servers with clients every month. Some folks were interested. Access control: in last call. Some discussion of special-purpose principal search reports. DASL draft: Revived in WebDAV WG rather than defunct DASL WG. Julian Reschke planning 2 separate drafts. The framework draft will cover the model and the request/response syntax. A separate mailing list exists for DASL, but some comments are mirrored on the WebDAV mailing list. Search framework issues: character comparison, how to discover what search arbiter to search namespace portion, what are search arbiters? Not special resources. Is any collection a potential search arbiter? Need for "more results" query. Issue: there is some overlap of issues between DASL and XML Query. However, XML Query doesn't handle marshalling, for example. Coordination between DASL and XML is needed. Query: member of XML Query working group will review DASL. Individual drafts related to WebDAV: - tickets (proposal to support tickets for access control by unnamed users) - quota (proposal to expose 2 named properties to handle quota on collections: size and quota limit in bytes) - property datatypes Proposal to W3C to do XML element datatyping, predated XML schemas - Ordering Long list of dead drafts & proposals either dead or sleeping - bindings, redirect references, ordered collections, property registration proposal, property namespace and allprop, use of dublin core metadata in dav, additional webdav ... (take from slide) comment: since drafts expire after 6 months, these proposals are dead unless re-raised. Issue of differing use models driving WebDAV development in different directions - use WebDAV as a file system. - Use to work on local repository and publish/share to WebDAV. - Synchronized use model, work on local store and sync, work from any machine, online or offline. - Acrobat use webdav repositories for annotations when not for the documents themselves. - Webdav for Web Site authoring and not for much for file sharing. Some evidence: webdav getting more interest from PC users, increasing press. WebDAV tutorial at AIIM (document & content management folks). Many document management tutorials. Article in PC magazine. RFC 2518bis (potentially) closed issues --------------------------------------- For moving to Draft, need two independent interoperable implementations of every feature: two clients & two servers for each feature. Use and meaning of allprop? If allprop doesn't mean "all properties" what does it mean? Proposal: all properties defined in 2518 plus all dead properties client sets, but not live properties defined in other drafts. This has already been put into practice by servers, and that wasn't an issue at the interop event. Who controls lock owner field? Client does. If a server-controlled field is needed, this will have to be done in a separate draft, not in RFC2518 bis. When to refresh a lock timeout? Nobody implemented what the document said. New model: only a lock refresh request refreshes the lock. Where root of repository may be? Some clients couldn't handle servers where path elements that aren't webdav resources. Some servers couldn't do what some clients wanted. This has been clarified, in http://host/a/b/c/d, http://host/a/b might not be a webdav resource. lock-null resources were removed from the spec. Most of the complex lock-null features weren't being used. A simpler model of creating a locked empty regular resource seems to be interoperable, it even work with clients that can lock unmapped URLs. Removed propertybehavior feature. Open issues in RFC2518bis ------------------------- If header Don't know what to do with the 'if' header. Ambiguities in the specification lead to clients not implementing complex behavior. The syntax doesn't support multiline values, which could mean problems when large header values must appear all in one header. E.g. IIS5 locks only resources, not collections, which results in many more locks in some situations. Operating on a collection containing many locked resources requires specifying different tagged lock tokens for each resource in If header. This results in such header length that web intermediaries cause problems. How to apply with Depth and Destination headers? "If" header confuses two purposes: - conditional which clients requires to be met - provision of lock token, which server requires to be there Implementations seem to be more forgiving than spec suggests. Can we demonstrate use or interoperability for Tagged production? boolean combination logic support? Use of ETags in "If" header? Proposal: only use "if" header for a list of lock tokens. Possible fix: add a header that does only one thing well, comma-delimited lock tokens? Possible fix: describe current behavior of the if header, and leave it at that. Dirk: If no-one is using the original if-header as originally specified: it's like there are two 'if' headers, maybe would allow existing syntax that clients use to be continue to be used, but in a more liberal way. This is one of the thorniest issues. Source Property Another remaining issue: with the 'source' property. Have there been any implementations? (appears to be none) Proposal: remove 'source' property Those against this proposal (not present but their arguments were recapped) say that one can't use WebDAV for what it was originally intended to do, without source property Those against this proposal fall into two camps. 1: source property is fine, we just need to put ourselves out to demonstrate interoperability. 2: source is not fine, let's use replacement that actually works Does the source property actually works? One known problem with source property: 2518 doesn't define how to present and describe multiple sources Brief discussion of using (Microsoft) Translate header. It's a boolean flag in a header. What it really means is "I'm in authoring mode" or "I'm in browsing mode". If header is missing, browser is assumed. "Translate: F" when present asks for source rather than result. This is included in all authoring client requests. Although Translate doesn't handle multiple source files directly either, it's possible that it addresses scenarios that are required to be addressed. May have some advantages. For example, since it's present on all requests, the server can infer other preferences like 'PROPFIND returns size of original files'. From w3c-dist-auth-request@w3.org Wed Mar 20 17:19:28 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17209 for ; Wed, 20 Mar 2002 17:19:28 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id D73DA22C2D; Wed, 20 Mar 2002 17:19:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA25227; Wed, 20 Mar 2002 17:18:46 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 17:18:46 -0500 (EST) Resent-Message-Id: <200203202218.RAA25227@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 RAA25071 for ; Wed, 20 Mar 2002 17:18:21 -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 RAA01660 for ; Wed, 20 Mar 2002 17:18:21 -0500 Received: from LIILMTLSFE02.mailtask.com ([208.203.59.43]) by LIILMTLSSM01.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 16:17:49 -0600 Received: from moose ([166.63.189.216]) by LIILMTLSFE02.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 16:17:50 -0600 From: "Lisa Dusseault" To: Date: Wed, 20 Mar 2002 13:34:07 -0800 Message-ID: <000001c1d05d$49de83e0$d8bd3fa6@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 X-OriginalArrivalTime: 20 Mar 2002 22:17:50.0190 (UTC) FILETIME=[125FF8E0:01C1D05D] Subject: WebDAV and Service Location Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6076 X-Loop: w3c-dist-auth@w3.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 been looking into the problem of locating WebDAV servers on an intranet. Companies that have WebDAV servers on their net may not wish to have users manually configure various clients with the names of all those servers. In researching this problem, I've found only one standards-based approach, and that's SLP. Who would be interested in defining a WebDAV extension so that Service Location Protocol (SLP) clients can distinguish WebDAV servers from plain Web servers? Any feedback on how this should work? Or are there other options I'm ignorant of? The SLP specification: http://www.ietf.org/rfc/rfc2608.txt SLP home page, links to open source project: http://www.srvloc.org/ SLP and the Macintosh: http://www.opendoor.com/shareway/SLP.html Some background... SLP models SLP works in one of two models. In the direct client-to-server model, the client multicasts requests for a particular kind of service to the local network. Services of that type respond directly (unicast) to the client. I see problems with this model because it would require a WebDAV server to receive multicast. The second SLP model involves a directory agent to register services: +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ | User | | Directory | |Service | | Agent | | Agent | | Agent | +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+ This model seems easier for WebDAV servers to implement (they just have to send their registration and accept the response). Service URLs Services advertise themselves using service names or schemes. As HTTP servers, WebDAV servers would probably therefore advertise themselves with the 'http' service type. E.g. service:http://myserver.com A client request for "service:http" would match against all HTTP and WebDAV servers advertising themselves in this way. For all matches, a list of attributes for the service can be returned to the client. I suspect the attribute list is the right place to advertise WebDAV support. This optimizes in a few directions: - to find all HTTP servers, whether WebDAV or not, the client only needs to send one service match request. - to find all WebDAV servers, the client only needs to send one request, and has to filter out the non-WebDAV responses. - It is not necessary for the client to send OPTIONS to all HTTP servers to discover WebDAV support. However, to discover additional WebDAV functionality that may be required unless we add additional detail. - HTTP/WebDAV servers only need to advertise themselves once, as a http service with WebDAV support attributes. This approach follows the approach for printers, which you can follow through examples in the RFC. Lisa From w3c-dist-auth-request@w3.org Wed Mar 20 17:23:27 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17343 for ; Wed, 20 Mar 2002 17:23:26 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 66E9722C47; Wed, 20 Mar 2002 17:23:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA26183; Wed, 20 Mar 2002 17:23:23 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 17:23:23 -0500 (EST) Resent-Message-Id: <200203202223.RAA26183@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 RAA26138 for ; Wed, 20 Mar 2002 17:22:59 -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 RAA02602 for ; Wed, 20 Mar 2002 17:23:00 -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 OAA09734 for ; Wed, 20 Mar 2002 14:22:57 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 20 Mar 2002 14:23: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: RE: how to specify extension features in response to OPTIONS request Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6077 X-Loop: w3c-dist-auth@w3.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 Also accidentally caught by the spam filter. - Jim -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Tuesday, March 19, 2002 6:23 PM To: 'Greg Stein'; 'Julian Reschke'; 'Sohn, Matthias' Cc: ietf-dav-versioning@w3.org; w3c-dist-auth@w3.org Subject: [Moderator Action] RE: how to specify extension features in response to OPTIONS request > There was some amount of consensus a while back on the DAV WG > list that the > DAV: header should allow Coded-URLs in it. mod_dav took this > approach, so an > OPTIONS response looks like: If Greg's approach is taken to avoid conflicts, then I see no strong reason to prefer live properties over OPTIONS header values in the general case. However, if the feature is one which relates only to some resources (e.g. all collections support the feature, or all resources in the directory foo, etc) then it might be helpful to advertise support for the feature only on those resources, using a live property as suggested. OPTIONS * still seems to be the most appropriate place to marshall server-wide features, with the conflict-avoidance caveats already mentioned. Lisa From w3c-dist-auth-request@w3.org Wed Mar 20 17:49:35 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18130 for ; Wed, 20 Mar 2002 17:49:34 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id E772D22BBA; Wed, 20 Mar 2002 17:49:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28744; Wed, 20 Mar 2002 17:49:31 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 17:49:31 -0500 (EST) Resent-Message-Id: <200203202249.RAA28744@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 RAA28700 for ; Wed, 20 Mar 2002 17:49:21 -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 RAA06279 for ; Wed, 20 Mar 2002 17:49:21 -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 g2KMoVl28407 for ; Wed, 20 Mar 2002 14:50: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 g2KMnCq01082 for ; Wed, 20 Mar 2002 14:49:12 -0800 (PST) Received: from ham-dhcp-122-226.eur.adobe.com ([130.248.122.226]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GTAND800.VUA; Wed, 20 Mar 2002 14:48:44 -0800 Date: Wed, 20 Mar 2002 23:49:01 +0100 Mime-Version: 1.0 (Apple Message framework v481) Cc: Message-Id: In-Reply-To: <000001c1d05d$49de83e0$d8bd3fa6@moose> Content-Type: text/plain; charset=US-ASCII; format=flowed From: Daniel Brotsky Content-Transfer-Encoding: 7bit To: "Lisa Dusseault" X-Mailer: Apple Mail (2.481) Subject: Re: WebDAV and Service Location Protocol Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6078 X-Loop: w3c-dist-auth@w3.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 Great find, Lisa. This is an issue we've been starting to focus on at Adobe, as well. I would be willing to collaborate on defining a WebDAV extension for SLP Service Agents (and interested clients). dan On Wednesday, March 20, 2002, at 10:34 PM, Lisa Dusseault wrote: > > I've been looking into the problem of locating WebDAV servers on an > intranet. Companies that have WebDAV servers on their net may not > wish to > have users manually configure various clients with the names of all > those > servers. In researching this problem, I've found only one > standards-based > approach, and that's SLP. > > Who would be interested in defining a WebDAV extension so that Service > Location Protocol (SLP) clients can distinguish WebDAV servers from > plain > Web servers? Any feedback on how this should work? Or are there other > options I'm ignorant of? > > The SLP specification: http://www.ietf.org/rfc/rfc2608.txt > SLP home page, links to open source project: http://www.srvloc.org/ > SLP and the Macintosh: http://www.opendoor.com/shareway/SLP.html > > Some background... > > SLP models > > SLP works in one of two models. In the direct client-to-server model, > the > client multicasts requests for a particular kind of service to the local > network. Services of that type respond directly (unicast) to the > client. I > see problems with this model because it would require a WebDAV server to > receive multicast. > > The second SLP model involves a directory agent to register services: > > +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ > | User | | Directory | |Service | > | Agent | | Agent | | Agent | > +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+ > > This model seems easier for WebDAV servers to implement (they just have > to > send their registration and accept the response). > > Service URLs > > Services advertise themselves using service names or schemes. As HTTP > servers, WebDAV servers would probably therefore advertise themselves > with > the 'http' service type. E.g. > > service:http://myserver.com > > A client request for "service:http" would match against all HTTP and > WebDAV > servers advertising themselves in this way. For all matches, a list of > attributes for the service can be returned to the client. I suspect the > attribute list is the right place to advertise WebDAV support. This > optimizes in a few directions: > - to find all HTTP servers, whether WebDAV or not, the client only > needs to > send one service match request. > - to find all WebDAV servers, the client only needs to send one > request, > and has to filter out the non-WebDAV responses. > - It is not necessary for the client to send OPTIONS to all HTTP > servers to > discover WebDAV support. However, to discover additional WebDAV > functionality that may be required unless we add additional detail. > - HTTP/WebDAV servers only need to advertise themselves once, as a http > service with WebDAV support attributes. > > This approach follows the approach for printers, which you can follow > through examples in the RFC. > > Lisa > From w3c-dist-auth-request@w3.org Wed Mar 20 18:08:16 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18438 for ; Wed, 20 Mar 2002 18:08:16 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 9B33222BDA; Wed, 20 Mar 2002 18:08:19 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA00621; Wed, 20 Mar 2002 18:08:09 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 18:08:09 -0500 (EST) Resent-Message-Id: <200203202308.SAA00621@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 SAA00479 for ; Wed, 20 Mar 2002 18:07:19 -0500 (EST) Received: from waka.wakasoft.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 SAA08945 for ; Wed, 20 Mar 2002 18:07:19 -0500 Received: (from fielding@localhost) by waka.wakasoft.com (8.11.0/8.11.0) id g2KN2N801885; Wed, 20 Mar 2002 15:02:23 -0800 Date: Wed, 20 Mar 2002 15:02:23 -0800 From: "Roy T. Fielding" To: Lisa Dusseault Cc: w3c-dist-auth@w3.org Message-ID: <20020320150223.B1297@waka.wakasoft.com> References: <002c01c1d053$e7cded20$ecba3fa6@moose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01c1d053$e7cded20$ecba3fa6@moose> User-Agent: Mutt/1.3.20i Subject: Re: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6079 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Authoring clients do not go through edge services, period. DAV clients always operate on the origin of content, not replications of it. If an edge service (transformation configuration) itself is authorable, then it will be authored via a completely different authority than the resources that it transforms. ....Roy From w3c-dist-auth-request@w3.org Wed Mar 20 21:04:57 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21646 for ; Wed, 20 Mar 2002 21:04:56 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 62DC522C3D; Wed, 20 Mar 2002 21:04:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA16978; Wed, 20 Mar 2002 21:04:38 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 21:04:38 -0500 (EST) Resent-Message-Id: <200203210204.VAA16978@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 VAA16895 for ; Wed, 20 Mar 2002 21:03:35 -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 VAA30140 for ; Wed, 20 Mar 2002 21:03:35 -0500 Received: from LIILMTLSFE02.mailtask.com ([208.203.59.43]) by LIILMTLSSM01.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 20:02:55 -0600 Received: from moose ([166.63.189.216]) by LIILMTLSFE02.mailtask.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Mar 2002 20:02:55 -0600 From: "Lisa Dusseault" To: "'Roy T. Fielding'" Cc: Date: Wed, 20 Mar 2002 18:04:28 -0800 Message-ID: <001101c1d07c$bc0e7230$d8bd3fa6@moose> 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20020320150223.B1297@waka.wakasoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 21 Mar 2002 02:02:55.0651 (UTC) FILETIME=[8441C730:01C1D07C] Subject: RE: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6080 X-Loop: w3c-dist-auth@w3.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 don't think you understand. If I'm sitting inside a large company, trying to author a page from a site that's out on the internet, that page may already be subject to transformations from transparent edge services. For example, the company firewall may be filtering viruses downloaded via HTTP. More insidious, if I get my internet service from a struggling ISP, they could replace banner ads on incoming messages with their own banner ads. The OPES WG at the IETF is dealing with these issues directly. The IAB has suggested that edge services should not be transparent -- that clients must explicitly ask for edge services. However, even an IETF demand for there not to be transparent edge services isn't a guarantee that there won't be any. You could say that the authoring issues are an argument against encouraging transparent edge services, but those issues certainly don't make transparent edge services not exist. Lisa > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@apache.org] > Sent: Wednesday, March 20, 2002 3:02 PM > To: Lisa Dusseault > Cc: w3c-dist-auth@w3.org > Subject: Re: WebDAV and Open Pluggable Edge Services > > > Authoring clients do not go through edge services, period. > DAV clients > always operate on the origin of content, not replications of > it. If an > edge service (transformation configuration) itself is authorable, then > it will be authored via a completely different authority than > the resources > that it transforms. > > ....Roy From w3c-dist-auth-request@w3.org Wed Mar 20 22:22:48 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23697 for ; Wed, 20 Mar 2002 22:22:48 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 3C8A022BE4; Wed, 20 Mar 2002 22:22:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA25643; Wed, 20 Mar 2002 22:00:54 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 22:00:54 -0500 (EST) Resent-Message-Id: <200203210300.WAA25643@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 VAA25350 for ; Wed, 20 Mar 2002 21:59:29 -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 VAA07008 for ; Wed, 20 Mar 2002 21:59: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.01; Wed, 20 Mar 2002 21:56:42 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 21:58:56 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1063C34BF@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 20 Mar 2002 21:58:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6081 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Roy that it doesn't make sense to talk about authoring the results of a transformation, unless that transformation is designed to be invertible, which is usually not the case. In order for it to be suitable for authoring, the inversion would have to send essential authoring metadata (such as locks) back to the "actual" source. About the only inversion that is likely to be supported is effectively a link directly back to the actual source (pretty much like what the DAV:source property would do). Roy's point was not that edge services don't exist (obviously, they do), but rather that authoring requests will not target the results of the edge service, but will target the original source that is the basis for what is produced by the edge service. So it may be interesting to develop protocols for controlling and requesting edge services, but this is largely orthogonal to the distributed authoring issues that are the focus of WebDAV (other than the need for a DAV:source property that jumps you from the results of the edge service back to the appropriate source resources). Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:ldusseault@xythos.com] Sent: Wednesday, March 20, 2002 9:04 PM To: 'Roy T. Fielding' Cc: w3c-dist-auth@w3.org Subject: RE: WebDAV and Open Pluggable Edge Services I don't think you understand. If I'm sitting inside a large company, trying to author a page from a site that's out on the internet, that page may already be subject to transformations from transparent edge services. For example, the company firewall may be filtering viruses downloaded via HTTP. More insidious, if I get my internet service from a struggling ISP, they could replace banner ads on incoming messages with their own banner ads. The OPES WG at the IETF is dealing with these issues directly. The IAB has suggested that edge services should not be transparent -- that clients must explicitly ask for edge services. However, even an IETF demand for there not to be transparent edge services isn't a guarantee that there won't be any. You could say that the authoring issues are an argument against encouraging transparent edge services, but those issues certainly don't make transparent edge services not exist. Lisa > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@apache.org] > Sent: Wednesday, March 20, 2002 3:02 PM > To: Lisa Dusseault > Cc: w3c-dist-auth@w3.org > Subject: Re: WebDAV and Open Pluggable Edge Services > > > Authoring clients do not go through edge services, period. > DAV clients > always operate on the origin of content, not replications of > it. If an > edge service (transformation configuration) itself is authorable, then > it will be authored via a completely different authority than > the resources > that it transforms. > > ....Roy From w3c-dist-auth-request@w3.org Wed Mar 20 23:43:44 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25996 for ; Wed, 20 Mar 2002 23:43:44 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id EA85122C40; Wed, 20 Mar 2002 23:43:47 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA08107; Wed, 20 Mar 2002 23:43:41 -0500 (EST) Resent-Date: Wed, 20 Mar 2002 23:43:41 -0500 (EST) Resent-Message-Id: <200203210443.XAA08107@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 XAA08069 for ; Wed, 20 Mar 2002 23:43:19 -0500 (EST) Received: from waka.wakasoft.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 XAA22621 for ; Wed, 20 Mar 2002 23:43:18 -0500 Received: (from fielding@localhost) by waka.wakasoft.com (8.11.0/8.11.0) id g2L4dk402680; Wed, 20 Mar 2002 20:39:46 -0800 Date: Wed, 20 Mar 2002 20:39:46 -0800 From: "Roy T. Fielding" To: Lisa Dusseault Cc: w3c-dist-auth@w3.org Message-ID: <20020320203946.A2645@waka.wakasoft.com> References: <20020320150223.B1297@waka.wakasoft.com> <001101c1d07c$bc0e7230$d8bd3fa6@moose> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001101c1d07c$bc0e7230$d8bd3fa6@moose> User-Agent: Mutt/1.3.20i Subject: Re: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6082 X-Loop: w3c-dist-auth@w3.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, Mar 20, 2002 at 06:04:28PM -0800, Lisa Dusseault wrote: > I don't think you understand. If I'm sitting inside a large company, trying > to author a page from a site that's out on the internet, that page may > already be subject to transformations from transparent edge services. For > example, the company firewall may be filtering viruses downloaded via HTTP. I don't think that DAV clients should be able to bypass that one, but they can via a tunnel. > More insidious, if I get my internet service from a struggling ISP, they > could replace banner ads on incoming messages with their own banner ads. I don't think people will allow banner ads to be edited through anything less secure than a VPM or SSL tunnel, for obvious reasons. > The OPES WG at the IETF is dealing with these issues directly. The IAB has > suggested that edge services should not be transparent -- that clients must > explicitly ask for edge services. However, even an IETF demand for there > not to be transparent edge services isn't a guarantee that there won't be > any. You could say that the authoring issues are an argument against > encouraging transparent edge services, but those issues certainly don't make > transparent edge services not exist. I wouldn't argue that at all. What you should consider, however, is that if there is a plain HTTP mechanism for routing requests unmolested through an interception device (which is not called an edge service), then what makes you think that only DAV clients would want to use it? And, once that happens, why would the molesters honor the plain HTTP mechanism? ....Roy From w3c-dist-auth-request@w3.org Thu Mar 21 00:38:08 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26954 for ; Thu, 21 Mar 2002 00:38:08 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 36E7922B8E; Thu, 21 Mar 2002 00:38:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA11190; Thu, 21 Mar 2002 00:38:04 -0500 (EST) Resent-Date: Thu, 21 Mar 2002 00:38:04 -0500 (EST) Resent-Message-Id: <200203210538.AAA11190@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 AAA11098 for ; Thu, 21 Mar 2002 00:37:40 -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 AAA28410; Thu, 21 Mar 2002 00:37:40 -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 AAA180456; Thu, 21 Mar 2002 00:33:46 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2L5b6B192688; Thu, 21 Mar 2002 00:37:06 -0500 To: "Lisa Dusseault" Cc: w3c-dist-auth@w3.org, w3c-dist-auth-request@w3.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 21 Mar 2002 00:29:36 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 5.0.9a |January 7, 2002) at 03/21/2002 12:37:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6083 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << 2. The situation could be made easier if all WebDAV clients were able to include a header in GET requests indicating that the request is being made by an authoring client, not a browsing client. I suggest a header rather than a method, because a new method will not be supported for much longer, and won't interoperate with non-WebDAV servers. >> But it doesn't deal with websites that simply serve sample code... or anything else that might possibly trigger the transformations. This doesn't sound like a WebDAV specific issue. 2.5) Or... the server could specify that it not-be/be transformed with a flag, but this is not WebDAV specific again. << 3. The source property is no help in this situation. Doing a PROPFIND can get you the source property, but then a GET to the URL in that property may be subject to the same edge service transformations as the original URL. >> Yup. It doesn't hurt or help. << 4. End-to-end encryption and/or signatures are the ultimate way to stop edge services from transforming data. Perhaps the spec coudl use a recommendation that WebDAV servers SHOULD support TLS, and that WebDAV clients SHOULD attempt to use TLS, even for content that is also available unencrypted. However, there are some unsolved issues here. How does the client discover that the content available over TLS is the same as the content available over unsecured HTTP, in cases where the content doesn't need to be secured by TLS for ordinary browsers? Note that it's equally possible for the server to host *different* content on ports 80 and 443, so the client must be able to differentiate the two cases. >> I have no problem with recommending TLS, but in regard to edge servers this doesn't sound like a webdav specific issue. And WebDAV really isn't doing anything odd or surprising that should require special consideration by the OPES folks. The OPES guys simply need to do the right thing. Of course if someone see's it differently.... :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Mar 21 03:48:09 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07173 for ; Thu, 21 Mar 2002 03:48:09 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id E973322B88; Thu, 21 Mar 2002 03:48:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA29301; Thu, 21 Mar 2002 03:48:05 -0500 (EST) Resent-Date: Thu, 21 Mar 2002 03:48:05 -0500 (EST) Resent-Message-Id: <200203210848.DAA29301@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 DAA29273 for ; Thu, 21 Mar 2002 03:47:40 -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 DAA14852 for ; Thu, 21 Mar 2002 03:47:40 -0500 Received: (qmail 15713 invoked by uid 0); 21 Mar 2002 08:47:06 -0000 Received: from p3ee24715.dip.t-dialin.net (HELO lisa) (62.226.71.21) by mail.gmx.net (mp016-rz3) with SMTP; 21 Mar 2002 08:47:06 -0000 From: "Julian Reschke" To: "WebDAV" Date: Thu, 21 Mar 2002 09:47:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id DAA29273 Subject: status of efforts, was: [Moderator Action] WebDAV WG minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6084 X-Loop: w3c-dist-auth@w3.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 (I am splitting my comments into separate mails so that we get distinct discussion threads) > Minutes from WebDAV WG meeting > March 19, 2002 > 53rd IETF, Minneapolis > Reported by Larry Masinter, Adobe > > Chair present: Lisa Dusseault, Xythos > > > Status of Various Efforts > ------------------------- > > DeltaV: The DeltaV working group is closed, however issues are > still being discussed actively on the working group mailing list. > No interop events are planned as yet. > > Q: Any clients for DeltaV? TeamStream (Xythos web file client) is a > very limited client. Might assume that server vendors have > clients. SubVersion has a client, but will only work with SubVersion > for a while. - I happen to have tested the TeamStream client two days ago (with our server). It's good that there *is* a versioning-aware client, but the current implementation shows that it's not trivial to support the more advanced features. As far as I understand, it currently can *show* a (linear) version history (minus DAV:comment property), but it doesn't really support actions on the version resources (like opening, deleting and so on...) - Technically, our remote WebDAV adapter *is* a DeltaV client, and it's goal is to interoperate with any RFC3253 server. So far, we haven't found any server to test against except our own (Subversion and Xythos interop fails for various reasons). So I think an interop testing event with a special focus on deltaV would be extremely useful. > Interop Plans: WebDAV to Draft Standard requires demonstration > of interoperability of various features between independent > implementations. First interop was last August, another last fall, > want to start again this spring. > > Suggestion from Brotsky: schedule rolling, round-robin, server > interops, e.g., server-client pair have dates for focus on interop > issues. Match servers with clients every month. Some folks were > interested. - I think it would be a good thing to automate as much as possible. Test suites like Litmus are welcome and server developers should have a public test site for their latest code. > Access control: in last call. Some discussion of special-purpose > principal search reports. > > DASL draft: Revived in WebDAV WG rather than defunct DASL WG. Julian > Reschke planning 2 separate drafts. The framework draft will cover the > model and the request/response syntax. - Clarification: I'm not planning separate drafts. The plan is to issue new drafts as each of the sections becomes stable (framework, basicsearch, QSD...). Right now, the framework (SEARCH method, grammar discovery, error reporting) seems to be stable. The first draft will be submitted as soon the IETF accepts them again. > A separate mailing list exists for DASL, but some comments are > mirrored on the WebDAV mailing list. Search framework issues: > character comparison, how to discover what search arbiter to search > namespace portion, what are search arbiters? Not special resources. > Is any collection a potential search arbiter? Need for "more results" > query. > > > Issue: there is some overlap of issues between DASL and XML Query. > However, XML Query doesn't handle marshalling, for example. > Coordination between DASL and XML is needed. > Query: member of XML Query working group will review DASL. - That would be welcome. Ideally, DASL would just be about *applying* the basics from XML Query / XSLT to the WebDAV specific case. > Individual drafts related to WebDAV: > > - tickets (proposal to support tickets for access control by > unnamed users) > - quota (proposal to expose 2 named properties to handle > quota on collections: size and quota limit in bytes) > - property datatypes > Proposal to W3C to do XML element datatyping, predated > XML schemas - Clarification: it doesn't predate XML Schema -- it's completely in sync with it: > - Ordering - Draft 03 will be submitted next week (unless problems with the draft are reported before): > Long list of dead drafts & proposals > either dead or sleeping > - bindings, redirect references, ordered collections, - We would be interested to revive the BIND protocol / draft. > property registration proposal, property namespace and > allprop, use of dublin core metadata in dav, > additional webdav ... > (take from slide) > > comment: since drafts expire after 6 months, these proposals are > dead unless > re-raised. From w3c-dist-auth-request@w3.org Thu Mar 21 04:23:52 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07589 for ; Thu, 21 Mar 2002 04:23:52 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id F204022BCA; Thu, 21 Mar 2002 03:57:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA29696; Thu, 21 Mar 2002 03:57:28 -0500 (EST) Resent-Date: Thu, 21 Mar 2002 03:57:28 -0500 (EST) Resent-Message-Id: <200203210857.DAA29696@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 DAA29641 for ; Thu, 21 Mar 2002 03:57: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 DAA15631 for ; Thu, 21 Mar 2002 03:57:00 -0500 Received: (qmail 18421 invoked by uid 0); 21 Mar 2002 08:56:27 -0000 Received: from p3ee24715.dip.t-dialin.net (HELO lisa) (62.226.71.21) by mail.gmx.net (mp016-rz3) with SMTP; 21 Mar 2002 08:56:27 -0000 From: "Julian Reschke" To: "WebDAV" Date: Thu, 21 Mar 2002 09:56:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id DAA29641 Subject: RFC2518bis, was: [Moderator Action] WebDAV WG minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6085 X-Loop: w3c-dist-auth@w3.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 > Minutes from WebDAV WG meeting > March 19, 2002 > 53rd IETF, Minneapolis > Reported by Larry Masinter, Adobe > > Chair present: Lisa Dusseault, Xythos > > > RFC 2518bis (potentially) closed issues > --------------------------------------- > > For moving to Draft, need two independent interoperable > implementations of every feature: two clients & two servers for each > feature. > > Use and meaning of allprop? If allprop doesn't mean "all properties" > what does it mean? Proposal: all properties defined in 2518 plus all > dead properties client sets, but not live properties defined in other > drafts. This has already been put into practice by servers, and that > wasn't an issue at the interop event. We still have the open issue to define a protocol extension that allows to PROPFIND all dead properties plus a set of named live properties in a single call. Proposal at: > Who controls lock owner field? Client does. If a server-controlled > field is needed, this will have to be done in a separate draft, not > in RFC2518 bis. Question: is there any intention to bundle all RFC2518 extensions (allprop behaviour, live deltaV properties, REPORT method, DAV:source property...) into a single WebDAV extension RFC? I think this would make a lot of sense. > When to refresh a lock timeout? Nobody implemented what the document > said. New model: only a lock refresh request refreshes the lock. > > Where root of repository may be? Some clients couldn't handle > servers where path elements that aren't webdav resources. > Some servers couldn't do what some clients wanted. This has > been clarified, in http://host/a/b/c/d, http://host/a/b might > not be a webdav resource. ...and should be clarified to Microsoft as well :-). > ... > > Source Property > > Another remaining issue: with the 'source' property. Have there > been any implementations? (appears to be none) > > Proposal: remove 'source' property ...and attempt a new definition in a new document. > Those against this proposal (not present but their arguments were > recapped) say that one can't use WebDAV for what it was originally > intended to do, without source property > > Those against this proposal fall into two camps. > 1: source property is fine, we just need to put ourselves out to > demonstrate interoperability. > 2: source is not fine, let's use replacement that actually works > > Does the source property actually works? One known problem with > source property: 2518 doesn't define how to present and describe > multiple sources I think it does, but there are several other problems with the current definition (already captured in the issues list). > Brief discussion of using (Microsoft) Translate header. It's a boolean > flag in a header. What it really means is "I'm in authoring mode" or > "I'm in browsing mode". If header is missing, browser is assumed. > > "Translate: F" when present asks for source rather than result. This > is included in all authoring client requests. > > Although Translate doesn't handle multiple source files directly > either, it's possible that it addresses scenarios that are required to be > addressed. > > May have some advantages. For example, since it's present on all > requests, the server can infer other preferences like > 'PROPFIND returns size of original files'. I don't want to restart the thread, but the "advantage" mentioned here is that the Translate header "solves" a problem that you wouldn't have in the first place when properly distinguishing source and output resources :-) From w3c-dist-auth-request@w3.org Thu Mar 21 11:00:48 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14651 for ; Thu, 21 Mar 2002 11:00:47 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 8BABC22C41; Thu, 21 Mar 2002 11:00:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA20367; Thu, 21 Mar 2002 11:00:34 -0500 (EST) Resent-Date: Thu, 21 Mar 2002 11:00:34 -0500 (EST) Resent-Message-Id: <200203211600.LAA20367@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 LAA20299 for ; Thu, 21 Mar 2002 11:00:10 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA29894 for ; Thu, 21 Mar 2002 11:00:10 -0500 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2LFxed04667 for ; Thu, 21 Mar 2002 07:59:40 -0800 (PST) Received: from SIVAJ-W2K2.cisco.com ([10.34.251.229] (may be forged)) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id HAA09303 for ; Thu, 21 Mar 2002 07:59:39 -0800 (PST) Message-Id: <4.3.2.7.2.20020321075719.018ad170@mira-sjcm-4.cisco.com> X-Sender: sivaj@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Mar 2002 07:59:38 -0800 To: w3c-dist-auth@w3.org From: Siva Jayasenan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Unsubscribing... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6086 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Could someone tell me how to unsubscribe from this mailing list? I forgotten how I got into this in the first place. Thanks, Siva.... Siva S. Jayasenan Core IP Eng - Services & Security, ITD From w3c-dist-auth-request@w3.org Thu Mar 21 13:43:29 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21187 for ; Thu, 21 Mar 2002 13:43:29 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 78F3022C7C; Thu, 21 Mar 2002 13:43:30 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA24292; Thu, 21 Mar 2002 13:42:55 -0500 (EST) Resent-Date: Thu, 21 Mar 2002 13:42:55 -0500 (EST) Resent-Message-Id: <200203211842.NAA24292@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 NAA24162 for ; Thu, 21 Mar 2002 13:42:17 -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 NAA01906 for ; Thu, 21 Mar 2002 13:42:16 -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 KAA28935; Thu, 21 Mar 2002 10:42:09 -0800 (PST) From: "Jim Whitehead" To: "Siva Jayasenan" , Date: Thu, 21 Mar 2002 10:42:18 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <4.3.2.7.2.20020321075719.018ad170@mira-sjcm-4.cisco.com> Subject: RE: Unsubscribing... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6087 X-Loop: w3c-dist-auth@w3.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 To unsubscribe from the WebDAV mailing list, you send a message to: w3c-dist-auth-request@w3.org With a subject line of: "unsubscribe" - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Siva Jayasenan > Sent: Thursday, March 21, 2002 8:00 AM > To: w3c-dist-auth@w3.org > Subject: Unsubscribing... > > > Could someone tell me how to unsubscribe from this mailing list? I > forgotten how I got into this in the first place. > > Thanks, > Siva.... > Siva S. Jayasenan > Core IP Eng - Services & Security, ITD From w3c-dist-auth-request@w3.org Thu Mar 21 14:17:18 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21995 for ; Thu, 21 Mar 2002 14:17:18 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 5D09022BCB; Thu, 21 Mar 2002 14:17:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA28914; Thu, 21 Mar 2002 14:17:16 -0500 (EST) Resent-Date: Thu, 21 Mar 2002 14:17:16 -0500 (EST) Resent-Message-Id: <200203211917.OAA28914@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 OAA28770 for ; Thu, 21 Mar 2002 14:16: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 OAA10433 for ; Thu, 21 Mar 2002 14:16:49 -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 g2LJHx626245 for ; Thu, 21 Mar 2002 11:17:59 -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 g2LJEjY06514 for ; Thu, 21 Mar 2002 11:14:45 -0800 (PST) Received: from larrypad ([130.248.184.147]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GTC87100.S81 for ; Thu, 21 Mar 2002 11:16:13 -0800 Reply-To: From: "Larry Masinter" To: Date: Thu, 21 Mar 2002 11:16:15 -0800 Message-ID: <001f01c1d10c$df48afa0$baba3fa6@larrypad> 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, Build 10.0.3416 In-Reply-To: <002c01c1d053$e7cded20$ecba3fa6@moose> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6088 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm reviewing the HTTP spec and the Cache-Control: no-transform directive; RFC 2616 section 14.9.5. To prevent transformations of authored content, servers could respond, when the client is "authoring", with a no-transform. But I'm less sure of the utility of the Cache-Control: no-transform request; does it mean "don't transform the request" or does it mean "don't transform the response?". And would it apply to an origin server as another way of saying a kind of "translate"? Note that authoring clients should be sensitive to Warning 214 (Transformation applied). At least, then there would be some belief that they wouldn't inadvertently try to let the user edit something that wasn't the original source. I'm not sure how a DAV server would know whether to supply a cache-control: no-transform if clients distinguish between the resource and its source by the "DAV:source" property. (I was also wondering about the interaction between cache-control: no-transform and the vary header. A response with no-transform and one without no-transform are different. So if the decision to supply no-transform depends on a request header, then should the result Vary by that request header?) Larry -- http://larry.masinter.net From w3c-dist-auth-request@w3.org Thu Mar 21 19:44:00 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01386 for ; Thu, 21 Mar 2002 19:43:59 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 9A41022BCA; Thu, 21 Mar 2002 19:44:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA02949; Thu, 21 Mar 2002 19:43:56 -0500 (EST) Resent-Date: Thu, 21 Mar 2002 19:43:56 -0500 (EST) Resent-Message-Id: <200203220043.TAA02949@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 TAA02923 for ; Thu, 21 Mar 2002 19:43:29 -0500 (EST) Received: from web9908.mail.yahoo.com (web9908.mail.yahoo.com [216.136.129.251]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA04748 for ; Thu, 21 Mar 2002 19:43:28 -0500 Message-ID: <20020322004328.66148.qmail@web9908.mail.yahoo.com> Received: from [63.214.191.66] by web9908.mail.yahoo.com via HTTP; Thu, 21 Mar 2002 16:43:28 PST Date: Thu, 21 Mar 2002 16:43:28 -0800 (PST) From: Michael Datuin To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Anyone have any MS web folder/Rosebud sample code? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6089 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Does anyone have any experience/knowledge on using MS OLE DB Provider for Internet Publishing (aka, Rosebud)? I'm looking for C/C++ (not VB) sample code that shows how to open files from and save files to a MS web folder. I've looked high and low on msdn.microsoft.com for "understandable and useful" information regarding web folders, but to no avail. The link to the sample Sample1 program on the MS website for OLE DB Provider for Internet Publishing doesn't even provide a link to download the example!!! I found references to the WebFolder objects and such, but all I want is a C/C++ example that I can use to add to my Win32 application. Are there any sample code that shows how to open/save files with MS web folders?!?!?! I've seen many requests for help regarding sample code to programmatically (using C/C++) access MS web folders, and MS web folders in general, but never any responses. Frustrating! __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From w3c-dist-auth-request@w3.org Fri Mar 22 08:06:21 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20334 for ; Fri, 22 Mar 2002 08:06:20 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 5B57E22C43; Fri, 22 Mar 2002 07:23:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA02249; Fri, 22 Mar 2002 07:23:02 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 07:23:02 -0500 (EST) Resent-Message-Id: <200203221223.HAA02249@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 HAA02180 for ; Fri, 22 Mar 2002 07:22:35 -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 HAA32539 for ; Fri, 22 Mar 2002 07:22: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 ; Fri, 22 Mar 2002 13:22:16 +0100 Date: Fri, 22 Mar 2002 13:22:16 +0100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Stefan Eissing To: In-Reply-To: <001f01c1d10c$df48afa0$baba3fa6@larrypad> Message-Id: <72AC4F9C-3D8F-11D6-893C-00039384827E@greenbytes.de> 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id HAA02180 Subject: Re: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6091 X-Loop: w3c-dist-auth@w3.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 Am Donnerstag den, 21. März 2002, um 20:16, schrieb Larry Masinter: > I'm reviewing the HTTP spec and the Cache-Control: no-transform > directive; RFC 2616 section 14.9.5. > > To prevent transformations of authored content, servers could > respond, when the client is "authoring", with a no-transform. That would set us back to sending Translate headers. > But I'm less sure of the utility of the Cache-Control: no-transform > request; does it mean "don't transform the request" or does > it mean "don't transform the response?". And would it apply > to an origin server as another way of saying a kind of "translate"? Hmm, 2616 is only speaking of content (and Content- headers). The examples are with server responses. I think modifying client requests is a no-no. Otherwise I hope Internet Explorer sets "no-transform" when I'm online shopping... > Note that authoring clients should be sensitive to > Warning 214 (Transformation applied). At least, then > there would be some belief that they wouldn't inadvertently > try to let the user edit something that wasn't the original > source. Everyday you learn some new HTTP Headers...;) > I'm not sure how a DAV server would know whether to supply > a cache-control: no-transform if clients distinguish between > the resource and its source by the "DAV:source" property. Can a "source" resources (listed in some other resource's DAV:source property) have own DAV:source properties? Must a resource designated as "source" be editable (e.g. support PUT) and will that PUT influence the content of its derived resource? When? I think we need clarification of the "source" concept. When do resources have a "source" relation? - ASP/JSP pages - shtml - executables, object files and source code - resources derived from a "master" with stylesheets - ... Which of these examples do we want to provide a solution for with DAV:source? > (I was also wondering about the interaction between > cache-control: no-transform and the vary header. A response > with no-transform and one without no-transform are different. > So if the decision to supply no-transform depends on a request > header, then should the result Vary by that request header? I'm not really a fan of new HTTP methods, but just for interest: Wouldn't a new method like "EDIT" which retrieves the editable content of a resource make our life easier? It could respond with a Content-Location where a PUT can be applied... //Stefan From w3c-dist-auth-request@w3.org Fri Mar 22 08:23:20 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20687 for ; Fri, 22 Mar 2002 08:23:20 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 3E4DC22CC0; Fri, 22 Mar 2002 08:23:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA09200; Fri, 22 Mar 2002 08:23:14 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 08:23:14 -0500 (EST) Resent-Message-Id: <200203221323.IAA09200@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 IAA09173 for ; Fri, 22 Mar 2002 08:22:48 -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 IAA07664 for ; Fri, 22 Mar 2002 08:22:48 -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 Mar 2002 08:19:59 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 08:22:17 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B1063C3892@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 22 Mar 2002 08:22:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6092 X-Loop: w3c-dist-auth@w3.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 you have a URL for the source (i.e. the one that PUT can be applied to), what benefit would EDIT (previously called GETSRC in the recent thread on this subject) have, other than saving you one roundtrip, i.e. instead of a "PROPFIND, GET" you would do an EDIT? In particular, if you are going to use locking for your authoring (which you should :-), you don't want to issue the GET until you have successfully LOCKed the URL (i.e. your sequence will be PROPFIND(source)/LOCK(source-URL)/GET(source-URL). So unless you also want to bundle an implict "LOCK" into the EDIT, you need to do the PROPFIND first anyway. Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] I'm not really a fan of new HTTP methods, but just for interest: Wouldn't a new method like "EDIT" which retrieves the editable content of a resource make our life easier? It could respond with a Content-Location where a PUT can be applied... From w3c-dist-auth-request@w3.org Fri Mar 22 08:28:21 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20792 for ; Fri, 22 Mar 2002 08:28:20 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 27B7D22C70; Fri, 22 Mar 2002 06:19:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA21197; Fri, 22 Mar 2002 02:43:03 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 02:43:03 -0500 (EST) Resent-Message-Id: <200203220743.CAA21197@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 CAA20915 for ; Fri, 22 Mar 2002 02:41:15 -0500 (EST) Received: from gremlin.ics.uci.edu (mmdf@gremlin.ics.uci.edu [128.195.1.70]) by tux.w3.org (8.9.3/8.9.3) with SMTP id CAA25950 for ; Fri, 22 Mar 2002 02:41:12 -0500 Received: from ics.uci.edu ( pv182069.reshsg.uci.edu [128.195.182.69] ) by gremlin-relay.ics.uci.edu id aa24609 ; 21 Mar 2002 23:41 PST Message-ID: <3C9AE05A.8090103@ics.uci.edu> Date: Thu, 21 Mar 2002 23:42:18 -0800 From: Joachim Feise Reply-To: jfeise@ics.uci.edu Organization: Univeristy of California, Irvine User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en,de MIME-Version: 1.0 To: Michael Datuin Cc: w3c-dist-auth@w3.org References: <20020322004328.66148.qmail@web9908.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Anyone have any MS web folder/Rosebud sample code? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6090 X-Loop: w3c-dist-auth@w3.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 Michael Datuin wrote: >Does anyone have any experience/knowledge on using >MS OLE DB Provider for Internet Publishing (aka, >Rosebud)? > >I'm looking for C/C++ (not VB) sample code that shows >how to open files from and save files to a MS web >folder. > >I've looked high and low on msdn.microsoft.com for >"understandable and useful" information regarding web >folders, but to no avail. The link to the sample >Sample1 program on the MS website for OLE DB Provider >for Internet Publishing doesn't even provide a link to >download the example!!! > >I found references to the WebFolder objects and such, >but all I want is a C/C++ example that I can use to >add >to my Win32 application. Are there any sample code >that shows how to open/save files with MS web >folders?!?!?! > >I've seen many requests for help regarding sample code >to programmatically (using C/C++) access MS web >folders, and MS web folders in general, but never any >responses. Frustrating! > I have used it in a commercial application. But it is rather painful to use and quite limited, so we are no longer using it and rolled our own library. Essentially, you need to use the interfaces specificed in the OLE DB 2.5 SDK: IRootBinder, IBindResource, IRowset, ICreateRow, etc. For example, for a PROPFIND, you get the IRootBinder interface, from that the IBindResource interface, then you call Bind on that, with a request for an IRowset interface. You can then use the standard OLE DB functions to operate on the rowset. File reading/writing is done through an IStream interface. So you have to think in database terms, and, of course, COM knowledge is required. -Joe From w3c-dist-auth-request@w3.org Fri Mar 22 09:48:32 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22926 for ; Fri, 22 Mar 2002 09:48:32 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 2446A22D16; Fri, 22 Mar 2002 09:48:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA21382; Fri, 22 Mar 2002 09:48:29 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 09:48:29 -0500 (EST) Resent-Message-Id: <200203221448.JAA21382@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 JAA21266 for ; Fri, 22 Mar 2002 09:48:03 -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 JAA23131 for ; Fri, 22 Mar 2002 09:48:02 -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 Mar 2002 15:47:17 +0100 Date: Fri, 22 Mar 2002 15:47:16 +0100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: Stefan Eissing To: w3c-dist-auth@w3.org In-Reply-To: <3906C56A7BD1F54593344C05BD1374B1063C3892@SUS-MA1IT01> Message-Id: 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id JAA21266 Subject: Re: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6093 X-Loop: w3c-dist-auth@w3.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 Good that I asked. Besides locking, one would miss Versioning and Acls using some kind of EDIT/GETSRC method (not caring about source URLs). So, coming back to HTTP, variants and no-transform, I conclude that on editable "source" resources servers should: - send always "Cache-Control: no-transform" in GET responses - not vary the response to a GET on any HTTP header (??? I'm not sure about this one. Julian keeps on editing variants in his arguments...) That leaves the question: how does a WebDAV client know that a resource is editable, e.g. that a GET will retrieve someting that can be PUT back modified again later? Users working on a local copy of resources for a week would be a little disappointed when the server denies the upload afterwards. And you cannot deduce from successful write LOCKs that a resource content can be changed. Locking is also used for property and acl modifications... So what is a honest client supposed to do? //Stefan Am Freitag den, 22. März 2002, um 14:22, schrieb Clemm, Geoff: > If you have a URL for the source (i.e. the one that PUT > can be applied to), what benefit would EDIT (previously > called GETSRC in the recent thread on this subject) have, > other than saving you one roundtrip, i.e. instead of a > "PROPFIND, GET" you would do an EDIT? > > In particular, if you are going to use locking for your > authoring (which you should :-), you don't want to issue the GET > until you have successfully LOCKed the URL (i.e. your sequence > will be PROPFIND(source)/LOCK(source-URL)/GET(source-URL). > So unless you also want to bundle an implict "LOCK" into the EDIT, > you need to do the PROPFIND first anyway. > > Cheers, > Geoff > > -----Original Message----- > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > > I'm not really a fan of new HTTP methods, but just for interest: > Wouldn't a new method like "EDIT" which retrieves the editable > content of a resource make our life easier? It could respond > with a Content-Location where a PUT can be applied... > From w3c-dist-auth-request@w3.org Fri Mar 22 09:57:37 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23120 for ; Fri, 22 Mar 2002 09:57:37 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 02EBD22CFA; Fri, 22 Mar 2002 09:57:32 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA22799; Fri, 22 Mar 2002 09:57:27 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 09:57:27 -0500 (EST) Resent-Message-Id: <200203221457.JAA22799@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 JAA22754 for ; Fri, 22 Mar 2002 09:56: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 JAA25204 for ; Fri, 22 Mar 2002 09:56:55 -0500 Received: (qmail 16594 invoked by uid 0); 22 Mar 2002 14:56:23 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp013-rz3) with SMTP; 22 Mar 2002 14:56:23 -0000 From: "Julian Reschke" To: "Stefan Eissing" , Date: Fri, 22 Mar 2002 15:56:23 +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: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6094 X-Loop: w3c-dist-auth@w3.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: Friday, March 22, 2002 3:47 PM > To: w3c-dist-auth@w3.org > Subject: Re: WebDAV and Open Pluggable Edge Services > > > Good that I asked. > > Besides locking, one would miss Versioning and Acls using > some kind of EDIT/GETSRC method (not caring about source > URLs). > > So, coming back to HTTP, variants and no-transform, I > conclude that on editable "source" resources servers > should: > - send always "Cache-Control: no-transform" in GET responses > - not vary the response to a GET on any HTTP header > (??? I'm not sure about this one. Julian keeps on > editing variants in his arguments...) I think it can be possible that PUT is possible even if the GET varies. This just means that the PUT will actually overwrite varying entity bodies as well. > That leaves the question: how does a WebDAV client know > that a resource is editable, e.g. that a GET will retrieve > someting that can be PUT back modified again later? > > Users working on a local copy of resources for a week would > be a little disappointed when the server denies the upload > afterwards. And you cannot deduce from successful write LOCKs > that a resource content can be changed. Locking is also used > for property and acl modifications... > > So what is a honest client supposed to do? May be we need a new live property indicating that it's "meaningful" to edit a particular resource? Note that the absence of DAV:source (or it being empty) wouldn't really mean the same thing... From w3c-dist-auth-request@w3.org Fri Mar 22 11:48:37 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25887 for ; Fri, 22 Mar 2002 11:48:36 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id B7D5022BBC; Fri, 22 Mar 2002 11:48:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA11788; Fri, 22 Mar 2002 11:48:31 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 11:48:31 -0500 (EST) Resent-Message-Id: <200203221648.LAA11788@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 LAA11761 for ; Fri, 22 Mar 2002 11:48:16 -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 LAA17516 for ; Fri, 22 Mar 2002 11:48:15 -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 Mar 2002 11:45:26 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 11:47:44 -0500 Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B0B7@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 22 Mar 2002 11:47:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id LAA11761 Subject: RE: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6095 X-Loop: w3c-dist-auth@w3.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 The "Allow" header that comes back from OPTIONS should contain "PUT" iff PUT is allowed on that resource. That's probably a reasonable way to detect authorability, assuming of course that servers are well-behaved wrt the Allow header. Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Friday, March 22, 2002 9:47 AM To: w3c-dist-auth@w3.org Subject: Re: WebDAV and Open Pluggable Edge Services Good that I asked. Besides locking, one would miss Versioning and Acls using some kind of EDIT/GETSRC method (not caring about source URLs). So, coming back to HTTP, variants and no-transform, I conclude that on editable "source" resources servers should: - send always "Cache-Control: no-transform" in GET responses - not vary the response to a GET on any HTTP header (??? I'm not sure about this one. Julian keeps on editing variants in his arguments...) That leaves the question: how does a WebDAV client know that a resource is editable, e.g. that a GET will retrieve someting that can be PUT back modified again later? Users working on a local copy of resources for a week would be a little disappointed when the server denies the upload afterwards. And you cannot deduce from successful write LOCKs that a resource content can be changed. Locking is also used for property and acl modifications... So what is a honest client supposed to do? //Stefan Am Freitag den, 22. März 2002, um 14:22, schrieb Clemm, Geoff: > If you have a URL for the source (i.e. the one that PUT > can be applied to), what benefit would EDIT (previously > called GETSRC in the recent thread on this subject) have, > other than saving you one roundtrip, i.e. instead of a > "PROPFIND, GET" you would do an EDIT? > > In particular, if you are going to use locking for your > authoring (which you should :-), you don't want to issue the GET > until you have successfully LOCKed the URL (i.e. your sequence > will be PROPFIND(source)/LOCK(source-URL)/GET(source-URL). > So unless you also want to bundle an implict "LOCK" into the EDIT, > you need to do the PROPFIND first anyway. > > Cheers, > Geoff > > -----Original Message----- > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > > I'm not really a fan of new HTTP methods, but just for interest: > Wouldn't a new method like "EDIT" which retrieves the editable > content of a resource make our life easier? It could respond > with a Content-Location where a PUT can be applied... > From w3c-dist-auth-request@w3.org Fri Mar 22 11:54:46 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25996 for ; Fri, 22 Mar 2002 11:54:46 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 43BFD22CD5; Fri, 22 Mar 2002 11:54:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA12165; Fri, 22 Mar 2002 11:54:43 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 11:54:43 -0500 (EST) Resent-Message-Id: <200203221654.LAA12165@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 LAA12126 for ; Fri, 22 Mar 2002 11:54: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 LAA18938 for ; Fri, 22 Mar 2002 11:54:22 -0500 Received: (qmail 13297 invoked by uid 0); 22 Mar 2002 16:53:46 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 22 Mar 2002 16:53:46 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 22 Mar 2002 17:53:46 +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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B103F8B0B7@SUS-MA1IT01> Subject: RE: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6096 X-Loop: w3c-dist-auth@w3.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 Geoff, of course you're right. So am I -- however the live property is already there (DAV:supported-method-set). ;.) > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 22, 2002 5:48 PM > To: w3c-dist-auth@w3.org > Subject: RE: WebDAV and Open Pluggable Edge Services > > > The "Allow" header that comes back from OPTIONS should > contain "PUT" iff PUT is allowed on that resource. > That's probably a reasonable way to detect authorability, > assuming of course that servers are well-behaved wrt the > Allow header. > > Cheers, > Geoff > > -----Original Message----- > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > Sent: Friday, March 22, 2002 9:47 AM > To: w3c-dist-auth@w3.org > Subject: Re: WebDAV and Open Pluggable Edge Services > > > Good that I asked. > > Besides locking, one would miss Versioning and Acls using > some kind of EDIT/GETSRC method (not caring about source > URLs). > > So, coming back to HTTP, variants and no-transform, I > conclude that on editable "source" resources servers > should: > - send always "Cache-Control: no-transform" in GET responses > - not vary the response to a GET on any HTTP header > (??? I'm not sure about this one. Julian keeps on > editing variants in his arguments...) > > That leaves the question: how does a WebDAV client know > that a resource is editable, e.g. that a GET will retrieve > someting that can be PUT back modified again later? > > Users working on a local copy of resources for a week would > be a little disappointed when the server denies the upload > afterwards. And you cannot deduce from successful write LOCKs > that a resource content can be changed. Locking is also used > for property and acl modifications... > > So what is a honest client supposed to do? > > //Stefan > > Am Freitag den, 22. März 2002, um 14:22, schrieb Clemm, Geoff: > > > If you have a URL for the source (i.e. the one that PUT > > can be applied to), what benefit would EDIT (previously > > called GETSRC in the recent thread on this subject) have, > > other than saving you one roundtrip, i.e. instead of a > > "PROPFIND, GET" you would do an EDIT? > > > > In particular, if you are going to use locking for your > > authoring (which you should :-), you don't want to issue the GET > > until you have successfully LOCKed the URL (i.e. your sequence > > will be PROPFIND(source)/LOCK(source-URL)/GET(source-URL). > > So unless you also want to bundle an implict "LOCK" into the EDIT, > > you need to do the PROPFIND first anyway. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > > > > I'm not really a fan of new HTTP methods, but just for interest: > > Wouldn't a new method like "EDIT" which retrieves the editable > > content of a resource make our life easier? It could respond > > with a Content-Location where a PUT can be applied... > > > > From w3c-dist-auth-request@w3.org Fri Mar 22 14:12:22 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29069 for ; Fri, 22 Mar 2002 14:12:21 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id BADE122C10; Fri, 22 Mar 2002 14:12:23 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA00066; Fri, 22 Mar 2002 14:11:35 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 14:11:35 -0500 (EST) Resent-Message-Id: <200203221911.OAA00066@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 OAA29871 for ; Fri, 22 Mar 2002 14:10:56 -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 NAA06382 for ; Fri, 22 Mar 2002 13:41:29 -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 g2MIfPT05781; Fri, 22 Mar 2002 10:41:25 -0800 (PST) Received: from D36CF911 ([152.68.17.155]) by rgmgw1.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g2MIfVC16194; Fri, 22 Mar 2002 11:41:31 -0700 (MST) Message-ID: <054a01c1d1d0$69926890$9b114498@D36CF911> From: "Eric Sedlar" To: "Stefan Eissing" , References: <72AC4F9C-3D8F-11D6-893C-00039384827E@greenbytes.de> Date: Fri, 22 Mar 2002 10:35:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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: WebDAV and Open Pluggable Edge Services Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6098 X-Loop: w3c-dist-auth@w3.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 EDIT is the same thing as GETSRC/Translate. --Eric ----- Original Message ----- From: "Stefan Eissing" To: Sent: Friday, March 22, 2002 4:22 AM Subject: Re: WebDAV and Open Pluggable Edge Services > > Am Donnerstag den, 21. März 2002, um 20:16, schrieb Larry Masinter: > > > I'm reviewing the HTTP spec and the Cache-Control: no-transform > > directive; RFC 2616 section 14.9.5. > > > > To prevent transformations of authored content, servers could > > respond, when the client is "authoring", with a no-transform. > > That would set us back to sending Translate headers. > > > But I'm less sure of the utility of the Cache-Control: no-transform > > request; does it mean "don't transform the request" or does > > it mean "don't transform the response?". And would it apply > > to an origin server as another way of saying a kind of "translate"? > > Hmm, 2616 is only speaking of content (and Content- headers). The > examples are with server responses. > > I think modifying client requests is a no-no. Otherwise I > hope Internet Explorer sets "no-transform" when I'm online > shopping... > > > Note that authoring clients should be sensitive to > > Warning 214 (Transformation applied). At least, then > > there would be some belief that they wouldn't inadvertently > > try to let the user edit something that wasn't the original > > source. > > Everyday you learn some new HTTP Headers...;) > > > I'm not sure how a DAV server would know whether to supply > > a cache-control: no-transform if clients distinguish between > > the resource and its source by the "DAV:source" property. > > Can a "source" resources (listed in some other resource's > DAV:source property) have own DAV:source properties? > Must a resource designated as "source" be editable (e.g. support > PUT) and will that PUT influence the content of its > derived resource? When? > > I think we need clarification of the "source" concept. When > do resources have a "source" relation? > - ASP/JSP pages > - shtml > - executables, object files and source code > - resources derived from a "master" with stylesheets > - ... > > Which of these examples do we want to provide a solution > for with DAV:source? > > > (I was also wondering about the interaction between > > cache-control: no-transform and the vary header. A response > > with no-transform and one without no-transform are different. > > So if the decision to supply no-transform depends on a request > > header, then should the result Vary by that request header? > > I'm not really a fan of new HTTP methods, but just for interest: > Wouldn't a new method like "EDIT" which retrieves the editable > content of a resource make our life easier? It could respond > with a Content-Location where a PUT can be applied... > > //Stefan > > > > From w3c-dist-auth-request@w3.org Fri Mar 22 16:25:36 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02060 for ; Fri, 22 Mar 2002 16:25:35 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 3AD7B22D23; Fri, 22 Mar 2002 16:25:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA20112; Fri, 22 Mar 2002 12:41:11 -0500 (EST) Resent-Date: Fri, 22 Mar 2002 12:41:11 -0500 (EST) Resent-Message-Id: <200203221741.MAA20112@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 MAA19708 for ; Fri, 22 Mar 2002 12:40: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 MAA23148 for ; Fri, 22 Mar 2002 12:15:55 -0500 Received: (qmail 20298 invoked by uid 0); 22 Mar 2002 17:15:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 22 Mar 2002 17:15:24 -0000 From: "Julian Reschke" To: Date: Fri, 22 Mar 2002 18:15: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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: WebDAV properties vs. variants Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6097 X-Loop: w3c-dist-auth@w3.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 think we need to clarify how HTTP variants relate to WebDAV properties. 1) The headers returned upon HTTP's GET reflect meta-information about the entity which was returned. This in turn depends on the variant that was selected (based on context and request headers). 2) WebDAV's "get*" properties are defined to reflect whatever the entity headers for this resource would have been. I'd say this means that: 3) PROPFIND should use the same algorithm to internally select a version as GET. 4) Does this also mean that properties other than the "get*" properties reflect information about a specific variant and not the resource itself? Julian From w3c-dist-auth-request@w3.org Mon Mar 25 07:06:45 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07261 for ; Mon, 25 Mar 2002 07:06:45 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id C207622B78; Mon, 25 Mar 2002 07:06:46 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA16311; Mon, 25 Mar 2002 07:05:49 -0500 (EST) Resent-Date: Mon, 25 Mar 2002 07:05:49 -0500 (EST) Resent-Message-Id: <200203251205.HAA16311@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 HAA16236 for ; Mon, 25 Mar 2002 07:05:28 -0500 (EST) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA29668 for ; Mon, 25 Mar 2002 07:05:28 -0500 Received: from pcxwing (pc-enterprise [141.12.37.101]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with SMTP id NAA12802 for ; Mon, 25 Mar 2002 13:05:26 +0100 (MET) Message-ID: <000a01c1d3f5$efd8dde0$65250c8d@sit.fhg.de> From: "Sascha Boehm" To: "Webdav List" Date: Mon, 25 Mar 2002 13:09:38 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1D3FE.514DC650" 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: Internal Server Error 500 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6099 X-Loop: w3c-dist-auth@w3.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_0007_01C1D3FE.514DC650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I configured mod_dav with apache 1.3.20 and it seems to run. When using = cadaevr, I can connect and I see my site-documents. When I want to get a = site it works, too. But if I want to put a document, I get the following = message: dav:!> open localhost Looking up hostname... Connecting to server... connected. dav:/> put seite1.htm Uploading seite1.htm to `/seite1.htm': Progress: = [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>] 100.0% of 640 bytes failed: 500 Internal Server Error Following permissions I set: drwxr-xr-x 3 nobody wwwrun 4096 M=E4r 18 15:06 . drwxr-xr-x 14 root root 4096 M=E4r 21 09:50 .. -rwxr-xr-x 1 nobody wwwrun 2326 M=E4r 18 15:06 apache_pb.gif -rwxr-xr-x 1 nobody wwwrun 1884 M=E4r 18 15:06 index.html.ca -rwxr-xr-x 1 nobody wwwrun 1583 M=E4r 18 15:06 index.html.cz -rwxr-xr-x 1 nobody wwwrun 2274 M=E4r 18 15:06 index.html.de -rwxr-xr-x 1 nobody wwwrun 1557 M=E4r 18 15:06 index.html.dk -rwxr-xr-x 1 nobody wwwrun 1877 M=E4r 18 15:06 index.html.ee -rwxr-xr-x 1 nobody wwwrun 1677 M=E4r 18 15:06 index.html.el -rwxr-xr-x 1 nobody wwwrun 2673 M=E4r 18 15:06 index.html.en -rwxr-xr-x 1 nobody wwwrun 1799 M=E4r 18 15:06 index.html.es -rwxr-xr-x 1 nobody wwwrun 1525 M=E4r 18 15:06 index.html.fr -rwxr-xr-x 1 nobody wwwrun 3706 M=E4r 18 15:06 = index.html.he.iso8859-8 -rwxr-xr-x 1 nobody wwwrun 1847 M=E4r 18 15:06 index.html.it -rwxr-xr-x 1 nobody wwwrun 1799 M=E4r 18 15:06 = index.html.ja.jis -rwxr-xr-x 1 nobody wwwrun 1333 M=E4r 18 15:06 = index.html.kr.iso-kr -rwxr-xr-x 1 nobody wwwrun 1896 M=E4r 18 15:06 index.html.lu -rwxr-xr-x 1 nobody wwwrun 2007 M=E4r 18 15:06 index.html.nl -rwxr-xr-x 1 nobody wwwrun 1534 M=E4r 18 15:06 index.html.nn -rwxr-xr-x 1 nobody wwwrun 1526 M=E4r 18 15:06 index.html.no -rwxr-xr-x 1 nobody wwwrun 1497 M=E4r 18 15:06 = index.html.po.iso-pl -rwxr-xr-x 1 nobody wwwrun 1842 M=E4r 18 15:06 index.html.pt -rwxr-xr-x 1 nobody wwwrun 2035 M=E4r 18 15:06 = index.html.pt-br -rwxr-xr-x 1 nobody wwwrun 1591 M=E4r 18 15:06 = index.html.ru.cp-1251 -rwxr-xr-x 1 nobody wwwrun 1585 M=E4r 18 15:06 = index.html.ru.cp866 -rwxr-xr-x 1 nobody wwwrun 1589 M=E4r 18 15:06 = index.html.ru.iso-ru -rwxr-xr-x 1 nobody wwwrun 1585 M=E4r 18 15:06 = index.html.ru.koi8-r -rwxr-xr-x 1 nobody wwwrun 3134 M=E4r 18 15:06 = index.html.ru.ucs2 -rwxr-xr-x 1 nobody wwwrun 6268 M=E4r 18 15:06 = index.html.ru.ucs4 -rwxr-xr-x 1 nobody wwwrun 2318 M=E4r 18 15:06 = index.html.ru.utf8 -rwxr-xr-x 1 nobody wwwrun 1700 M=E4r 18 15:06 index.html.se -rwxr-xr-x 1 nobody wwwrun 1062 M=E4r 18 15:06 = index.html.zh.Big5 drwxr-xr-x 9 nobody wwwrun 4096 M=E4r 18 15:06 manual Can somebody help? thanks, Sascha Boehm ------=_NextPart_000_0007_01C1D3FE.514DC650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I configured mod_dav with apache 1.3.20 = and it=20 seems to run. When using cadaevr, I can connect and I see my = site-documents.=20 When I want to get a site it works, too. But if I want to put a = document, I get=20 the following message:
 
dav:!> open localhost
Looking up = hostname...=20 Connecting to server... connected.
dav:/> put = seite1.htm
Uploading=20 seite1.htm to `/seite1.htm':
Progress: = [=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>]=20 100.0% of 640 bytes failed:
500 Internal Server Error
 
Following permissions I = set:
 
 
drwxr-xr-x    3 = nobody  =20 wwwrun       4096 M=E4r 18 15:06=20 .
drwxr-xr-x   14 root    =20 root         4096 M=E4r 21 09:50 = ..
-rwxr-xr-x    1 nobody  =20 wwwrun       2326 M=E4r 18 15:06=20 apache_pb.gif
-rwxr-xr-x    1 nobody  =20 wwwrun       1884 M=E4r 18 15:06=20 index.html.ca
-rwxr-xr-x    1 nobody  =20 wwwrun       1583 M=E4r 18 15:06=20 index.html.cz
-rwxr-xr-x    1 nobody  =20 wwwrun       2274 M=E4r 18 15:06=20 index.html.de
-rwxr-xr-x    1 nobody  =20 wwwrun       1557 M=E4r 18 15:06=20 index.html.dk
-rwxr-xr-x    1 nobody  =20 wwwrun       1877 M=E4r 18 15:06=20 index.html.ee
-rwxr-xr-x    1 nobody  =20 wwwrun       1677 M=E4r 18 15:06=20 index.html.el
-rwxr-xr-x    1 nobody  =20 wwwrun       2673 M=E4r 18 15:06=20 index.html.en
-rwxr-xr-x    1 nobody  =20 wwwrun       1799 M=E4r 18 15:06=20 index.html.es
-rwxr-xr-x    1 nobody  =20 wwwrun       1525 M=E4r 18 15:06=20 index.html.fr
-rwxr-xr-x    1 nobody  =20 wwwrun       3706 M=E4r 18 15:06=20 index.html.he.iso8859-8
-rwxr-xr-x    1 = nobody  =20 wwwrun       1847 M=E4r 18 15:06=20 index.html.it
-rwxr-xr-x    1 nobody  =20 wwwrun       1799 M=E4r 18 15:06=20 index.html.ja.jis
-rwxr-xr-x    1 nobody  =20 wwwrun       1333 M=E4r 18 15:06=20 index.html.kr.iso-kr
-rwxr-xr-x    1 = nobody  =20 wwwrun       1896 M=E4r 18 15:06=20 index.html.lu
-rwxr-xr-x    1 nobody  =20 wwwrun       2007 M=E4r 18 15:06=20 index.html.nl
-rwxr-xr-x    1 nobody  =20 wwwrun       1534 M=E4r 18 15:06=20 index.html.nn
-rwxr-xr-x    1 nobody  =20 wwwrun       1526 M=E4r 18 15:06=20 index.html.no
-rwxr-xr-x    1 nobody  =20 wwwrun       1497 M=E4r 18 15:06=20 index.html.po.iso-pl
-rwxr-xr-x    1 = nobody  =20 wwwrun       1842 M=E4r 18 15:06=20 index.html.pt
-rwxr-xr-x    1 nobody  =20 wwwrun       2035 M=E4r 18 15:06=20 index.html.pt-br
-rwxr-xr-x    1 nobody  =20 wwwrun       1591 M=E4r 18 15:06=20 index.html.ru.cp-1251
-rwxr-xr-x    1 = nobody  =20 wwwrun       1585 M=E4r 18 15:06=20 index.html.ru.cp866
-rwxr-xr-x    1 nobody   = wwwrun       1589 M=E4r 18 15:06=20 index.html.ru.iso-ru
-rwxr-xr-x    1 = nobody  =20 wwwrun       1585 M=E4r 18 15:06=20 index.html.ru.koi8-r
-rwxr-xr-x    1 = nobody  =20 wwwrun       3134 M=E4r 18 15:06=20 index.html.ru.ucs2
-rwxr-xr-x    1 nobody  =20 wwwrun       6268 M=E4r 18 15:06=20 index.html.ru.ucs4
-rwxr-xr-x    1 nobody  =20 wwwrun       2318 M=E4r 18 15:06=20 index.html.ru.utf8
-rwxr-xr-x    1 nobody  =20 wwwrun       1700 M=E4r 18 15:06=20 index.html.se
-rwxr-xr-x    1 nobody  =20 wwwrun       1062 M=E4r 18 15:06=20 index.html.zh.Big5
drwxr-xr-x    9 nobody  =20 wwwrun       4096 M=E4r 18 15:06=20 manual
 
Can somebody help?
 
thanks,
 
Sascha Boehm
 
 
------=_NextPart_000_0007_01C1D3FE.514DC650-- From w3c-dist-auth-request@w3.org Mon Mar 25 22:58:57 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15037 for ; Mon, 25 Mar 2002 22:58:57 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 0BD2E22B5D; Mon, 25 Mar 2002 22:59:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA06134; Mon, 25 Mar 2002 22:58:55 -0500 (EST) Resent-Date: Mon, 25 Mar 2002 22:58:55 -0500 (EST) Resent-Message-Id: <200203260358.WAA06134@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 WAA06095 for ; Mon, 25 Mar 2002 22:58:26 -0500 (EST) Received: from web9901.mail.yahoo.com (web9901.mail.yahoo.com [216.136.129.36]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA10724 for ; Mon, 25 Mar 2002 22:58:26 -0500 Message-ID: <20020326035825.89277.qmail@web9901.mail.yahoo.com> Received: from [63.214.191.66] by web9901.mail.yahoo.com via HTTP; Mon, 25 Mar 2002 19:58:25 PST Date: Mon, 25 Mar 2002 19:58:25 -0800 (PST) From: Michael Datuin To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: How do you get the URL of a MS web folder? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6100 X-Loop: w3c-dist-auth@w3.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 another question regarding Microsoft's webfolders. I see that when you create a web folder under WinXP, and you open up the "My Network Places" dialog, you can see your current list of network connections and web folders, along with the URL that is associated with each web folder on your system. The URL appears in the "Comments" column of the dialog box if you have the display settings set to "Details" (as opposed to Thumbnails, Tiles, Icons, and List). Also, if you right-click on one of your web folders and select "Properties", another dialog box will appear showing the URL as the "Target" of your web folder. What APIs are available to get the "Target" or "Comments" strings? Or more directly, how do you obtain the URL "programmatically" via a VC++ Win32 API to get the URL of your webfolder. I have sample VC++ code that I whipped up that opens that displays the common file dialog. If you navigate via the dialog to your web folder, and select a file (for example, a text document), on the return from selecting the file and the closing of the dialog, the path/filename is set to something like c:\Documents and Settings\datuin\Local Setting\Temporary Internet Files\Content.IE.5\8X6FOLYF\test[1].txt Now, if I make modifications to this file and want to save the file back to the web folder, I don't know programmatically where/how to put the file back. Clearly, I can't just save the file back to the above directory on my PC. I have to do a "put" back to the original URL. Actually, in my application, I would rather have the user navigate to the web folder using the common file dialog, instead of having them enter in the URL and making my code remember the URL. The common file dialog must "somehow" know that the folder the user navigated to is a web folder, right? So, all I care about is where (i.e., the URL) the user wants to save (or open) his file. Does such an API exist? Sorry if this isn't the right forum to ask this question. I don't know of a MS-related forum/resource to ask webfolder-related questions. Any help would be appreciated! Thanks! __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From w3c-dist-auth-request@w3.org Tue Mar 26 04:24:37 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28012 for ; Tue, 26 Mar 2002 04:24:37 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id D0CB622BA3; Tue, 26 Mar 2002 04:24:39 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA01934; Tue, 26 Mar 2002 04:24:35 -0500 (EST) Resent-Date: Tue, 26 Mar 2002 04:24:35 -0500 (EST) Resent-Message-Id: <200203260924.EAA01934@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 EAA01901 for ; Tue, 26 Mar 2002 04:23:55 -0500 (EST) Received: from gremlin.ics.uci.edu (mmdf@gremlin.ics.uci.edu [128.195.1.70]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA14931 for ; Tue, 26 Mar 2002 04:23:55 -0500 Received: from ics.uci.edu ( pv182069.reshsg.uci.edu [128.195.182.69] ) by gremlin-relay.ics.uci.edu id aa03492 ; 26 Mar 2002 01:23 PST Message-ID: <3CA03E28.4040804@ics.uci.edu> Date: Tue, 26 Mar 2002 01:23:52 -0800 From: Joachim Feise Reply-To: jfeise@ics.uci.edu Organization: Univeristy of California, Irvine User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en,de MIME-Version: 1.0 To: Michael Datuin Cc: w3c-dist-auth@w3.org References: <20020326035825.89277.qmail@web9901.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: How do you get the URL of a MS web folder? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6101 X-Loop: w3c-dist-auth@w3.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 Michael Datuin wrote: >This is a another question regarding Microsoft's >webfolders. > >I see that when you create a web folder under WinXP, >and you open up the "My Network Places" dialog, you >can see your current list of network connections >and web folders, along with the URL that is associated >with each web folder on your system. The URL appears >in the "Comments" column of the dialog box if you have >the display settings set to "Details" (as opposed to >Thumbnails, Tiles, Icons, and List). Also, if you >right-click on one of your web folders and select >"Properties", another dialog box will appear showing >the URL as the "Target" of your web folder. > >What APIs are available to get the "Target" or >"Comments" strings? Or more directly, how do you >obtain the URL "programmatically" via a VC++ Win32 >API to get the URL of your webfolder. > >I have sample VC++ code that I whipped up that opens >that displays the common file dialog. If you navigate >via the dialog to your web folder, and select a file >(for example, a text document), on the return from >selecting the file and the closing of the dialog, >the path/filename is set to something like > > c:\Documents and Settings\datuin\Local >Setting\Temporary Internet >Files\Content.IE.5\8X6FOLYF\test[1].txt > >Now, if I make modifications to this file and want to >save the file back to the web folder, I don't know >programmatically where/how to put the file back. >Clearly, I can't just save the file back to the >above directory on my PC. I have to do a "put" back >to the original URL. > >Actually, in my application, I would rather have the >user navigate to the web folder using the common >file dialog, instead of having them enter in the URL >and making my code remember the URL. The common file >dialog must "somehow" know that the folder the user >navigated to is a web folder, right? So, all I care >about is where (i.e., the URL) the user wants to save >(or open) his file. Does such an API exist? > >Sorry if this isn't the right forum to ask this >question. I don't know of a MS-related forum/resource >to ask webfolder-related questions. > >Any help would be appreciated! Thanks! > This is all accessed through the shell COM interfaces. To my knowledge, the Webfolders UI is implemented as a shell extension. You interact with it like with any other shell extension. Nothing specific to Webfolders, except that the target is a URL and not a file. Point your newsreader to news.microsoft.com, the newsgroup is news:microsoft.public.platformsdk.shell -Joe From w3c-dist-auth-request@w3.org Tue Mar 26 21:42:06 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04859 for ; Tue, 26 Mar 2002 21:42:06 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id C220B22C44; Tue, 26 Mar 2002 21:42:08 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA10057; Tue, 26 Mar 2002 21:41:36 -0500 (EST) Resent-Date: Tue, 26 Mar 2002 21:41:36 -0500 (EST) Resent-Message-Id: <200203270241.VAA10057@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 VAA10013 for ; Tue, 26 Mar 2002 21:41:10 -0500 (EST) Received: from web11202.mail.yahoo.com (web11202.mail.yahoo.com [216.136.131.184]) by tux.w3.org (8.9.3/8.9.3) with SMTP id VAA20481 for ; Tue, 26 Mar 2002 21:41:10 -0500 Message-ID: <20020327024106.94793.qmail@web11202.mail.yahoo.com> Received: from [198.182.5.173] by web11202.mail.yahoo.com via HTTP; Tue, 26 Mar 2002 18:41:06 PST Date: Tue, 26 Mar 2002 18:41:06 -0800 (PST) From: hugh To: w3c-dist-auth@w3.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Authoring Web Service Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6102 X-Loop: w3c-dist-auth@w3.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 have just started learning about WebDAV and have a few thoughts/questions that someone on this group may be able to help with. I understand WebDAV to be a HTTP-extension-based protocol that enables functionality that is important to distributed authoring. When I looked at the draft specs, it appears that the method extensions seem to map to operations performed on authored resources and the payload of the message seems to be arguments of sorts to the WebDAV server for the method being invoked. I was wondering if the WebDAV specs (and sub-specs) would be amenable to extrapolation to a general-purpose Web-Services interface definition and whether there would be any point in thinking this way. As a newbie to this technology, it seems like an obvious connection to me. In fact I suspect that I will find a whole bunch of other initiatives to define WSDL interfaces for "content managerment" or "distributed authoring" or.. Thank you for any pointers to discussions or links to related topics! __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ From w3c-dist-auth-request@w3.org Thu Mar 28 10:29:09 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00604 for ; Thu, 28 Mar 2002 10:29:09 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 9297522C98; Thu, 28 Mar 2002 10:29:12 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA24575; Thu, 28 Mar 2002 10:28:48 -0500 (EST) Resent-Date: Thu, 28 Mar 2002 10:28:48 -0500 (EST) Resent-Message-Id: <200203281528.KAA24575@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 KAA24496 for ; Thu, 28 Mar 2002 10:28:14 -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 KAA13061 for ; Thu, 28 Mar 2002 10:28:14 -0500 Received: (qmail 12078 invoked by uid 0); 28 Mar 2002 15:27:43 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 28 Mar 2002 15:27:43 -0000 From: "Julian Reschke" To: Date: Thu, 28 Mar 2002 16:27: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) In-Reply-To: <3CA03E28.4040804@ics.uci.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: Internet Draft Submission: draft-reschke-webdav-allprop-include-01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6103 X-Loop: w3c-dist-auth@w3.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 the abstract: "Recent specifications extending the Web Distributed Authoring Protocol (WebDAV) restrict the set of properties returned automatically upon a PROPFIND/allprop request. This specification defines a method to add specific properties to the set of properties returned upon PROPFIND/allprop." From the change log: "Moved element out of "DAV:" namespace. Updated reference to deltaV (now RFC3253). Changed examples to explicitly use utf-8 encoding for HTTP content type and XML encoding. Updated WebDAV ACL reference to draft 07. Made sure figures fit in 72 columns. Split references into "Normative" and "Informative". " Links: Submitted version in HTML format: Current version: From w3c-dist-auth-request@w3.org Thu Mar 28 23:50:10 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26298 for ; Thu, 28 Mar 2002 23:50:10 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 0C56222C41; Thu, 28 Mar 2002 23:50:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA15968; Thu, 28 Mar 2002 23:50:09 -0500 (EST) Resent-Date: Thu, 28 Mar 2002 23:50:09 -0500 (EST) Resent-Message-Id: <200203290450.XAA15968@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 XAA15588 for ; Thu, 28 Mar 2002 23:49:29 -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 XAA02066 for ; Thu, 28 Mar 2002 23:49:28 -0500 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id UAA09513 for ; Thu, 28 Mar 2002 20:55:34 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 28 Mar 2002 20:49:23 -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: Outlook Web Access Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6105 X-Loop: w3c-dist-auth@w3.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: Sean Kronberg [mailto:skronberg@viack.com] Sent: Thursday, March 28, 2002 1:07 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] RE: Outlook Web Access Please reply directly to skronberg@viack.com I'm trying to customize OWA to include a list of all users in our global address book (GAL). The search URL looks like this, however I'm looking for a "wildcard" for the display name (DN=) https://mail.viack.com/exchange/?Cmd=galfind&DN=**&LN=&FN=&TL=&AN=&CP=&D P=&OF=&CY= So, where the ** is in the above URL, I need a wildcard that works -- do you know of one? Thanks, Sean From w3c-dist-auth-request@w3.org Fri Mar 29 00:55:19 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27003 for ; Fri, 29 Mar 2002 00:55:18 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 496BE22B56; Thu, 28 Mar 2002 23:49:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA15707; Thu, 28 Mar 2002 23:49:48 -0500 (EST) Resent-Date: Thu, 28 Mar 2002 23:49:48 -0500 (EST) Resent-Message-Id: <200203290449.XAA15707@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 XAA15584 for ; Thu, 28 Mar 2002 23:49:28 -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 XAA02065 for ; Thu, 28 Mar 2002 23:49:28 -0500 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id UAA09516 for ; Thu, 28 Mar 2002 20:55:35 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 28 Mar 2002 20:49:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C1D69A.0AEBD5A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FW: [Moderator Action] Webdav Search with IIS Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6104 X-Loop: w3c-dist-auth@w3.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_0001_01C1D69A.0AEBD5A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Webdav Search with IISAccidentally caught by the spam filter. - Jim -----Original Message----- From: Thomas Fritz [mailto:Thomas.Fritz@da-ag.com] Sent: Wednesday, March 27, 2002 11:23 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Webdav Search with IIS I want to search for file properties with WebDAV on the Internet Information Services (together with Indexing Service). Unfortunately in the MSDN there is no real documentation for WebDAV Search Requests for the IIS only for the SharePoint Portal Server. Does anyone know a good reference for such search requests especially for the 'WHERE'-clause, because the results I got for my attempts are very curious. For example the code: var sQuery = "Select DAV:displayname, DAV:creationdate FROM SCOPE() WHERE not(\"DAV:getcontentlength\" != 1039)"; var oXML = new ActiveXObject('Msxml2.XMLHTTP.4.0'); oXML.open('SEARCH','http://mywebdav_2002/webtest1/',false); oXML.setRequestHeader('Depth:','1'); oXML.setRequestHeader('Content-Type:','text/xml'); oXML.send('' + sQuery + ''); alert(oXML.responseText); supplies the correct result with status 207 in the response but if I change the 'sQuery' to: var sQuery = "Select DAV:displayname, DAV:creationdate FROM SCOPE() WHERE (\"DAV:getcontentlength\" = 1039)"; I only get an empty response with status 207. Furthermore I do not know how to query a special creationdate or collections and so on... Can anyone help me? Thomas Fritz Thomas.Fritz@da-ag.com ------=_NextPart_000_0001_01C1D69A.0AEBD5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Webdav Search with IIS
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Thomas Fritz=20 [mailto:Thomas.Fritz@da-ag.com]
Sent: Wednesday, March 27, = 2002 11:23=20 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator = Action]=20 Webdav Search with IIS

I want to search for file properties with = WebDAV on=20 the Internet Information Services (together with Indexing Service). =

Unfortunately in the MSDN there is no = real=20 documentation for WebDAV Search Requests for the IIS only for the = SharePoint=20 Portal Server. Does anyone know a good reference for such search = requests=20 especially for the 'WHERE'-clause, because the results I got for my = attempts are=20 very curious.

For example the code:
var sQuery =3D "Select DAV:displayname, DAV:creationdate FROM = SCOPE() WHERE=20 not(\"DAV:getcontentlength\" !=3D 1039)";

var oXML =3D new=20 ActiveXObject('Msxml2.XMLHTTP.4.0');
oXML.open('SEARCH','http://mywebdav_2002/web= test1/',false);=20
oXML.setRequestHeader('Depth:','1');=20
oXML.setRequestHeader('Content-Type:','text/xml');

oXML.send('<?xml=20 version=3D"1.0"?><g:searchrequest = xmlns:g=3D"DAV:"><g:sql>' + sQuery=20 + '</g:sql></g:searchrequest>');

alert(oXML.responseText);


supplies the correct result with status = 207 in the=20 response but if I change the 'sQuery' to:
var=20 sQuery =3D "Select DAV:displayname, DAV:creationdate FROM SCOPE() WHERE=20 (\"DAV:getcontentlength\" =3D 1039)";
I only=20 get an empty response with status 207.

Furthermore I do not know how to query a = special=20 creationdate or collections and so on...

Can anyone help me?


Thomas Fritz
Thomas.Fritz@da-ag.com =

------=_NextPart_000_0001_01C1D69A.0AEBD5A0-- From w3c-dist-auth-request@w3.org Fri Mar 29 07:04:47 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09383 for ; Fri, 29 Mar 2002 07:04:47 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 90B8322C53; Fri, 29 Mar 2002 07:04:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA03800; Fri, 29 Mar 2002 07:04:19 -0500 (EST) Resent-Date: Fri, 29 Mar 2002 07:04:19 -0500 (EST) Resent-Message-Id: <200203291204.HAA03800@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 HAA03556 for ; Fri, 29 Mar 2002 07:03:36 -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 HAA22050 for ; Fri, 29 Mar 2002 07:03:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09316; Fri, 29 Mar 2002 07:03:32 -0500 (EST) Message-Id: <200203291203.HAA09316@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: Fri, 29 Mar 2002 07:03:31 -0500 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6106 X-Loop: w3c-dist-auth@w3.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 : WebDAV Ordered Collections Protocol Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford, J. Reschke Filename : draft-ietf-webdav-ordering-protocol-02.txt Pages : 43 Date : 28-Mar-02 This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-02.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-ordering-protocol-02.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-ordering-protocol-02.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: <20020328141519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020328141519.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Fri Mar 29 08:09:52 2002 Received: from wiggum.w3.org (wiggum.w3.org [18.29.0.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11057 for ; Fri, 29 Mar 2002 08:09:52 -0500 (EST) Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by wiggum.w3.org (Postfix) with ESMTP id 7F53722B9C; Fri, 29 Mar 2002 08:09:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA11190; Fri, 29 Mar 2002 08:09:50 -0500 (EST) Resent-Date: Fri, 29 Mar 2002 08:09:50 -0500 (EST) Resent-Message-Id: <200203291309.IAA11190@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 IAA11169 for ; Fri, 29 Mar 2002 08:09:43 -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 IAA28659 for ; Fri, 29 Mar 2002 08:09:43 -0500 Received: (qmail 26834 invoked by uid 0); 29 Mar 2002 13:09:08 -0000 Received: from p3ee2470f.dip.t-dialin.net (HELO lisa) (62.226.71.15) by mail.gmx.net (mp013-rz3) with SMTP; 29 Mar 2002 13:09:08 -0000 From: "Julian Reschke" To: Date: Fri, 29 Mar 2002 14:09:11 +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: <200203291203.HAA09316@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: I-D ACTION:draft-ietf-webdav-ordering-protocol-02.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6107 X-Loop: w3c-dist-auth@w3.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, to clear up some possible confusion: For some reason, IETF has decided that the last submitted draft was version 01, and therefore assigned number 02. So now we have a March 2002 and a December 1999 version of draft 02. I feel that the protocol itself is stable and ready to be implemented. Before going to experimental RFC I'd like to rewrite some of the error reporting to be more in line with RFC3253 (WebDAV versioning). Our (greenbytes / SAP Portals) implementation of ordered collections is the only one I'm currently aware of. Does anybody know of another implementation? Regards, Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, March 29, 2002 1:04 PM > To: IETF-Announce: > Cc: w3c-dist-auth@w3.org > Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the WWW Distributed Authoring and > Versioning Working Group of the IETF. > > Title : WebDAV Ordered Collections Protocol > Author(s) : J. Slein, E. Whitehead, J. Davis, > G. Clemm, C. Fay, J. Crawford, J. Reschke > Filename : draft-ietf-webdav-ordering-protocol-02.txt > Pages : 43 > Date : 28-Mar-02 > > This specification extends the WebDAV Distributed Authoring Protocol > to support server-side ordering of collection members. Of particular > interest are orderings that are not based on property values, and so > cannot be achieved using a search protocol's ordering option and > cannot be maintained automatically by the server. Protocol elements > are defined to let clients specify the position in the ordering of > each collection member, as well as the semantics governing the > ordering. > Distribution of this document is unlimited. Please send comments to > the Distributed Authoring and Versioning (WebDAV) working group at > w3c-dist-auth@w3.org, which may be joined by sending a message with > subject 'subscribe' to w3c-dist-auth-request@w3.org. > Discussions of the WEBDAV working group are archived at URL: > http://lists.w3.org/Archives/Public/w3c-dist-auth/. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-pro > tocol-02.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-ordering-protocol-02.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-ordering-protocol-02.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. >