From w3c-dist-auth-request@w3.org Thu Aug 1 03:43:53 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08474 for ; Thu, 1 Aug 2002 03:43:53 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA07989; Thu, 1 Aug 2002 03:43:41 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g717hZ209690; Thu, 1 Aug 2002 03:43:35 -0400 (EDT) Resent-Date: Thu, 1 Aug 2002 03:43:35 -0400 (EDT) Resent-Message-Id: <200208010743.g717hZ209690@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g717hY709670 for ; Thu, 1 Aug 2002 03:43:34 -0400 (EDT) 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 DAA07957 for ; Thu, 1 Aug 2002 03:43:33 -0400 Received: (qmail 24129 invoked by uid 0); 1 Aug 2002 07:43:02 -0000 Received: from p3ee24703.dip.t-dialin.net (HELO lisa) (62.226.71.3) by mail.gmx.net (mp005-rz3) with SMTP; 1 Aug 2002 07:43:02 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Thu, 1 Aug 2002 09:42:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107A5D29A@SUS-MA1IT01> Importance: Normal Subject: Bindings, was: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6489 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, July 31, 2002 2:02 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Issue: URI_URL, proposed changes > > ... > > I also believe that it would be valuable to have a standard > property that identifies a URN for a resource, and that is > one goal of the binding spec (which we should be able to finish > up as soon as we have the ACL spec wrapped up). In particular, > the binding spec introduces the DAV:urn property for this purpose. > > I wouldn't want the DAV:source property confused with the DAV:urn > property. I'm not sure how the DAV:source property relates to bindings, but this is certainly a good opportunity to discuss some open issues with the BIND spec. I read some of the discussion from winter 2000 on the mailing list (just after submission of the 02 draft... [1]), and I'll try to summarize the main open points... 1) It seems to me that there is agreement on what a BIND is, and how the presence of multiple bindings to the same resource affects DELETE. 2) As some recent discussion in the deltav mailing list showed, we already have situations where additional bindings are created as side effects of versioning operations. As a matter of fact, just because the BIND spec wasn't finished doesn't mean that there aren't already shipping WebDAV implementations that have to deal with bindings -- we're just lacking standardized methods to explicitly create them / to get additional information about them. 3) There was a disagreement about whether BIND should be applied (a) to the collection in which the mapping is to be created or (b) to a URI of the resource that should get the additional binding. Roy prefers (preferred) (a), and I think technically he's right. The WG prefers (preferred) (b), because that's consistent with COPY/MOVE. As a server implementor, I'd prefer (a) because it seems cleaner. 4) There was a violent disagreement whether there needs to be a mechanism to retrieve a globally unique identifier for the resource (which is not supposed to change once the resource is created). The current spec calls this DAV:resourceid, Geoff mentioned DAV:urn (drafts and memory out of sync?). The issue here seems to be that "identity" of a resource is hard to define. Looking from an implementators POV, a resource in a document repository certainly has identity defined by a row number in a database or an inode number in the file system (for instance). With this piece of information, a server can easily assign persistent URIs to these objects that survive renaming. Having this information available can help a client keeping it's caches consistent (it would know that an operation that affects one resource will affect all resources with the same DAV:resourceid as well). I'd like to understand whether somebody thinks that this is a problem (would that make that an optional feature, or would it have to be removed?)? However, from an abstract point of view, multiple URIs can identify the same resource even if they live on separate HTTP servers. In particular, the implementations wouldn't even know about the "other" URI, and it would be impossible require both servers to return the same DAV:resourceid. Seems we need better terminology here. 5) The spec defines a live property (DAV:bindings) that contains a list of a URI mappings to a resource. From a marshalling perspective, that's a bad thing. It can be expensive to compute (so we would have to enforce RFC3253 propfind/allprop behaviour). Furthermore, a particular user may not have the right to see all URI mappings, and that kind of information is hard to marshall inside a live property. I think this should be modernized to use an explicit REPORT instead. Julian [1] From w3c-dist-auth-request@w3.org Thu Aug 1 13:07:37 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07650 for ; Thu, 1 Aug 2002 13:07:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02727; Thu, 1 Aug 2002 13:07:07 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g71H6h926897; Thu, 1 Aug 2002 13:06:43 -0400 (EDT) Resent-Date: Thu, 1 Aug 2002 13:06:43 -0400 (EDT) Resent-Message-Id: <200208011706.g71H6h926897@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g71H6g726877 for ; Thu, 1 Aug 2002 13:06:42 -0400 (EDT) Received: from e1.ny.us.ibm.com. (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02556 for ; Thu, 1 Aug 2002 13:06:42 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com. (8.12.2/8.12.2) with ESMTP id g71H64bW027468; Thu, 1 Aug 2002 13:06:04 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g71H626m066514; Thu, 1 Aug 2002 13:06:02 -0400 To: "Jason Crawford" 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: Thu, 1 Aug 2002 12:49:06 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 08/01/2002 13:06:01 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE69BDFCB853A8f9e8a93df938690918c0ABBE69BDFCB853A" Content-Disposition: inline Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6490 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE69BDFCB853A8f9e8a93df938690918c0ABBE69BDFCB853A Content-type: text/plain; charset=US-ASCII Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as resolved... Resolved: 8/1/02: COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH. - MOVE should maintain the integrity of the resource in that all live properties and behaviors should remain live and have the same semantics at the new location as at the old location. If there is any doubt "same" is defined according to the resource author's concept of "this resource". If you'd like this changed, just speak up. :-) J. ------------------------------------------ Phone: 914-784-7569 --0__=0ABBE69BDFCB853A8f9e8a93df938690918c0ABBE69BDFCB853A Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as resolved...

Resolved: 8/1/02: COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH. - MOVE should maintain the integrity of the resource in that all live properties and behaviors should remain live and have the same semantics at the new location as at the old location. If there is any doubt "same" is defined according to the resource author's concept of "this resource".

If you'd like this changed, just speak up. :-)

J.


------------------------------------------
Phone: 914-784-7569
--0__=0ABBE69BDFCB853A8f9e8a93df938690918c0ABBE69BDFCB853A-- From w3c-dist-auth-request@w3.org Thu Aug 1 13:07:44 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07668 for ; Thu, 1 Aug 2002 13:07:44 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02738; Thu, 1 Aug 2002 13:07:10 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g71H6l326922; Thu, 1 Aug 2002 13:06:47 -0400 (EDT) Resent-Date: Thu, 1 Aug 2002 13:06:47 -0400 (EDT) Resent-Message-Id: <200208011706.g71H6l326922@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g71H6l726902 for ; Thu, 1 Aug 2002 13:06:47 -0400 (EDT) Received: from e1.ny.us.ibm.com. (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA02572 for ; Thu, 1 Aug 2002 13:06:45 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com. (8.12.2/8.12.2) with ESMTP id g71H65bW109864; Thu, 1 Aug 2002 13:06:05 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g71H626n066514; Thu, 1 Aug 2002 13:06:02 -0400 To: "Julian Reschke" Cc: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Thu, 1 Aug 2002 13:01:33 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 08/01/2002 13:06:02 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE69BDFC0EA818f9e8a93df938690918c0ABBE69BDFC0EA81" Content-Disposition: inline Subject: Re: Bindings, was: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6491 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE69BDFC0EA818f9e8a93df938690918c0ABBE69BDFC0EA81 Content-type: text/plain; charset=US-ASCII << However, from an abstract point of view, multiple URIs can identify the same resource even if they live on separate HTTP servers. In particular, the implementations wouldn't even know about the "other" URI, and it would be impossible require both servers to return the same DAV:resourceid. >> I believe you're talking about inter-server bindings. Because of garbage collection issues, I suspect the server that actually holds the resource will know about all bindings to the resource. But more importantly, I suspect all servers that bind to that resource will get the resourceid from the server that actually contains the resource just as they'd get other properties like the last modification date. Did you have something else in mind? I believe the resources should have a resourceid, but right now I can live with a proposal that lacks it. ------------------------------------------ Phone: 914-784-7569 --0__=0ABBE69BDFC0EA818f9e8a93df938690918c0ABBE69BDFC0EA81 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

<<
However, from an abstract point of view, multiple URIs can identify the same
resource even if they live on separate HTTP servers. In particular, the
implementations wouldn't even know about the "other" URI, and it would be
impossible require both servers to return the same DAV:resourceid.
>>

I believe you're talking about inter-server bindings.
Because of garbage collection issues, I suspect the server that actually
holds the resource will know about all bindings to the resource. But more
importantly, I suspect all servers that bind to that resource will get the
resourceid from the server that actually contains the resource just as
they'd get other properties like the last modification date.

Did you have something else in mind?

I believe the resources should have a resourceid, but right now I can live
with a proposal that lacks it.


------------------------------------------
Phone: 914-784-7569
--0__=0ABBE69BDFC0EA818f9e8a93df938690918c0ABBE69BDFC0EA81-- From w3c-dist-auth-request@w3.org Thu Aug 1 19:15:20 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20438 for ; Thu, 1 Aug 2002 19:15:20 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA27997; Thu, 1 Aug 2002 19:15:11 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g71NF8626129; Thu, 1 Aug 2002 19:15:08 -0400 (EDT) Resent-Date: Thu, 1 Aug 2002 19:15:08 -0400 (EDT) Resent-Message-Id: <200208012315.g71NF8626129@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g71NF3726105 for ; Thu, 1 Aug 2002 19:15:03 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA27986 for ; Thu, 1 Aug 2002 19:15:03 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g71NEi025308; Thu, 1 Aug 2002 16:14:48 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV" , Date: Thu, 1 Aug 2002 16:12:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: WebDAV Interoperability Event: New Dates Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6492 X-Loop: w3c-dist-auth@w3.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 dates of the WebDAV Interoperability Testing Event have been changed. The NEW dates are September 9-11, 2002. The purpose of the WebDAV Interoperability Testing Event is to gather together in one place multiple implementations of the WebDAV protocol, and then efficiently test multiple client/server pairs. The goal is to improve interoperability of the WebDAV protocol. What: WebDAV Interoperability Testing Event When: September 9-11, 2002 Where: Baskin Engineering Building, UC Santa Cruz Cost: $225 (to cover food, parking, sys. admin) -- bring check payable to UC Regents To register for the event, please send mail to Jim Whitehead, ejw@cs.ucsc.edu. So far, implementations from Apple, Adobe, Oracle, Microsoft, Xythos, Sambar Technologies, and UC Santa Cruz have indicated they will be present. - Jim From w3c-dist-auth-request@w3.org Thu Aug 1 23:52:35 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26666 for ; Thu, 1 Aug 2002 23:52:34 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA04177; Thu, 1 Aug 2002 23:52:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g723qLG20664; Thu, 1 Aug 2002 23:52:21 -0400 (EDT) Resent-Date: Thu, 1 Aug 2002 23:52:21 -0400 (EDT) Resent-Message-Id: <200208020352.g723qLG20664@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g723qK720644 for ; Thu, 1 Aug 2002 23:52:20 -0400 (EDT) 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 XAA04129 for ; Thu, 1 Aug 2002 23:52:20 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 01 Aug 2002 23:43:53 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 1 Aug 2002 23:51:48 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107BC5017@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Thu, 1 Aug 2002 23:51:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6493 X-Loop: w3c-dist-auth@w3.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: Julian Reschke [mailto:julian.reschke@gmx.de] There was a disagreement about whether BIND should be applied (a) to the collection in which the mapping is to be created or (b) to a URI of the resource that should get the additional binding. Roy prefers (preferred) (a), and I think technically he's right. The WG prefers (preferred) (b), because that's consistent with COPY/MOVE. As a server implementor, I'd prefer (a) because it seems cleaner. Either way is fine with me. There was a violent disagreement whether there needs to be a mechanism to retrieve a globally unique identifier for the resource (which is not supposed to change once the resource is created). The current spec calls this DAV:resourceid, Geoff mentioned DAV:urn (drafts and memory out of sync?). It will be interesting to see whether that violent disagreement still exists. In particular, I'd be interested in seeing an implementation that supports multiple bindings to a single resource, and doesn't support something like a DAV:resourceid property. The issue here seems to be that "identity" of a resource is hard to define. In general, yes, but multiple bindings to a given resource give you a way of defining identity in a protocol visible way. Looking from an implementators POV, a resource in a document repository certainly has identity defined by a row number in a database or an inode number in the file system (for instance). With this piece of information, a server can easily assign persistent URIs to these objects that survive renaming. Having this information available can help a client keeping it's caches consistent (it would know that an operation that affects one resource will affect all resources with the same DAV:resourceid as well). I'd like to understand whether somebody thinks that this is a problem (would that make that an optional feature, or would it have to be removed?)? I do not think it is a problem, and I believe it should be a required feature. However, from an abstract point of view, multiple URIs can identify the same resource even if they live on separate HTTP servers. In particular, the implementations wouldn't even know about the "other" URI, and it would be impossible require both servers to return the same DAV:resourceid. The only way the same resource could live on separate HTTP servers would be if the resource is immutable, or unless one server is intimately linked to the other (so that all changes made through one server to that resource are automatically available when accessing the resource from the other server). In either case, the server would be able to return the same DAV:resourceid. Seems we need better terminology here. Which terms do you think need to be replaced? 5) The spec defines a live property (DAV:bindings) that contains a list of a URI mappings to a resource. From a marshalling perspective, that's a bad thing. It can be expensive to compute (so we would have to enforce RFC3253 propfind/allprop behaviour). Which is what we should do. Furthermore, a particular user may not have the right to see all URI mappings, and that kind of information is hard to marshall inside a live property. I think this should be modernized to use an explicit REPORT instead. If a client wants to retrieve this information, they should be able to batch up that request with other live property information, and should be able to use functionality like the DAV:expand-property report to thread through it. Like other live properties with sensitive information (such as DAV:acl or DAV:version-history), the server will omit DAV:binding information for clients that are not permitted to see it. Reports should be only used when parameters are required for the request, and DAV:binding is not a parameterized request. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Aug 2 03:31:30 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10444 for ; Fri, 2 Aug 2002 03:31:30 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA27809; Fri, 2 Aug 2002 03:31:28 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g727VPx05233; Fri, 2 Aug 2002 03:31:25 -0400 (EDT) Resent-Date: Fri, 2 Aug 2002 03:31:25 -0400 (EDT) Resent-Message-Id: <200208020731.g727VPx05233@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g727VM705140 for ; Fri, 2 Aug 2002 03:31:22 -0400 (EDT) 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 DAA27796 for ; Fri, 2 Aug 2002 03:31:21 -0400 Received: (qmail 16946 invoked by uid 0); 2 Aug 2002 07:30:50 -0000 Received: from pd950c3fc.dip.t-dialin.net (HELO lisa) (217.80.195.252) by mail.gmx.net (mp010-rz3) with SMTP; 2 Aug 2002 07:30:50 -0000 From: "Julian Reschke" To: "Jason Crawford" Cc: "Clemm, Geoff" , Date: Fri, 2 Aug 2002 09:30:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C23A07.48D6BD50" 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: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6494 X-Loop: w3c-dist-auth@w3.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_01C23A07.48D6BD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH." I think *if* we say something like this we should warn that this may not produce a new resource that behaves the same under variant handling (because only one of possible multiple variants would be copied). -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Thursday, August 01, 2002 6:49 PM To: Jason Crawford Cc: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as resolved... Resolved: 8/1/02: COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH. - MOVE should maintain the integrity of the resource in that all live properties and behaviors should remain live and have the same semantics at the new location as at the old location. If there is any doubt "same" is defined according to the resource author's concept of "this resource". If you'd like this changed, just speak up. :-) J. ------------------------------------------ Phone: 914-784-7569 ------=_NextPart_000_0007_01C23A07.48D6BD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

"COPY should do the = equivalent of a=20 GET/PROPFIND followed by PUT/PROPPATCH."
 
I=20 think *if* we say something like this we should warn that this may not = produce a=20 new resource that behaves the same under variant handling (because only = one of=20 possible multiple variants would be copied).
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason=20 Crawford
Sent: Thursday, August 01, 2002 6:49 = PM
To: Jason=20 Crawford
Cc: Clemm, Geoff; = w3c-dist-auth@w3c.org
Subject:=20 RE: New RFC2518bis draft, COPY / MOVE of live = properities

Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as=20 resolved...

Resolved: 8/1/02: COPY should do the equivalent of = a=20 GET/PROPFIND followed by PUT/PROPPATCH. - MOVE should maintain the = integrity=20 of the resource in that all live properties and behaviors should = remain live=20 and have the same semantics at the new location as at the old = location. If=20 there is any doubt "same" is defined according to the resource = author's=20 concept of "this resource".

If you'd like this changed, just = speak up.=20 = :-)

J.


------------------------------------------
Ph= one:=20 914-784-7569

------=_NextPart_000_0007_01C23A07.48D6BD50-- From w3c-dist-auth-request@w3.org Fri Aug 2 03:41:00 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10549 for ; Fri, 2 Aug 2002 03:41:00 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA29060; Fri, 2 Aug 2002 03:39:53 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g727dqW06033; Fri, 2 Aug 2002 03:39:52 -0400 (EDT) Resent-Date: Fri, 2 Aug 2002 03:39:52 -0400 (EDT) Resent-Message-Id: <200208020739.g727dqW06033@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g727do706013 for ; Fri, 2 Aug 2002 03:39:50 -0400 (EDT) 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 DAA29049 for ; Fri, 2 Aug 2002 03:39:49 -0400 Received: (qmail 2878 invoked by uid 0); 2 Aug 2002 07:39:18 -0000 Received: from pd950c3fc.dip.t-dialin.net (HELO lisa) (217.80.195.252) by mail.gmx.net (mp006-rz3) with SMTP; 2 Aug 2002 07:39:18 -0000 From: "Julian Reschke" To: "Jason Crawford" , "'Webdav WG \(E-mail\)'" Cc: "Clemm, Geoff" Date: Fri, 2 Aug 2002 09:39:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Subject: RE: Bindings, was: Issue: URI_URL, proposed changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6495 X-Loop: w3c-dist-auth@w3.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 Jason Crawford > Sent: Thursday, August 01, 2002 7:02 PM > To: Julian Reschke > Cc: Clemm, Geoff; 'Webdav WG (E-mail)' > Subject: Re: Bindings, was: Issue: URI_URL, proposed changes > > > << > However, from an abstract point of view, multiple URIs can identify the same > resource even if they live on separate HTTP servers. In particular, the > implementations wouldn't even know about the "other" URI, and it would be > impossible require both servers to return the same DAV:resourceid. > >> > > I believe you're talking about inter-server bindings. See, that's the issue. Whether you consider two resources to be the "same" depends on your POV, and the layer you're look at. Consider the URI: humanlanguage:en:HTML%20version%of%RFC2518 I just made it up, and it identifies an abstract resource. I can claim that the following URIs identify the same resource: http://greenbytes.de/tech/webdav/rfc2518.html http://ftp.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.html However, nobody will argue that this is the same type of "sameness" as described in the BIND protocol. So, no, I wasn't talking about inter-server bindings. > Because of garbage collection issues, I suspect the server that actually > holds the resource will know about all bindings to the resource. But more > importantly, I suspect all servers that bind to that resource will get the > resourceid from the server that actually contains the resource just as > they'd get other properties like the last modification date. > > Did you have something else in mind? > > I believe the resources should have a resourceid, but right now I can live > with a proposal that lacks it. From w3c-dist-auth-request@w3.org Fri Aug 2 03:54:27 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10805 for ; Fri, 2 Aug 2002 03:54:27 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA30868; Fri, 2 Aug 2002 03:53:00 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g727qx107475; Fri, 2 Aug 2002 03:52:59 -0400 (EDT) Resent-Date: Fri, 2 Aug 2002 03:52:59 -0400 (EDT) Resent-Message-Id: <200208020752.g727qx107475@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g727qw707455 for ; Fri, 2 Aug 2002 03:52:58 -0400 (EDT) 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 DAA30851 for ; Fri, 2 Aug 2002 03:52:57 -0400 Received: (qmail 14109 invoked by uid 0); 2 Aug 2002 07:52:55 -0000 Received: from pd950c3fc.dip.t-dialin.net (HELO lisa) (217.80.195.252) by mail.gmx.net (mp012-rz3) with SMTP; 2 Aug 2002 07:52:55 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Fri, 2 Aug 2002 09:52:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107BC5017@SUS-MA1IT01> Subject: RE: Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6496 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, August 02, 2002 5:52 AM > To: 'Webdav WG (E-mail)' > Subject: RE: Bindings > > .. > > However, from an abstract point of view, multiple URIs can identify > the same resource even if they live on separate HTTP servers. > In particular, the implementations wouldn't even know about the > "other" URI, and it would be impossible require both servers to > return the same DAV:resourceid. > > The only way the same resource could live on separate HTTP servers > would be if the resource is immutable, or unless one server is > intimately linked to the other (so that all changes made through one > server to that resource are automatically available when accessing > the resource from the other server). In either case, the server > would be able to return the same DAV:resourceid. (see separate answer). > Seems we need better terminology here. > > Which terms do you think need to be replaced? I think "same resource" only works when using it in a very technical sense. It won't when using it in the generic sense when identifying abstract concepts. > Furthermore, a particular user may not have the right to see all > URI mappings, and that kind of information is hard to marshall > inside a live property. I think this should be modernized to use an > explicit REPORT instead. > > If a client wants to retrieve this information, they should be able to > batch up that request with other live property information, and should > be able to use functionality like the DAV:expand-property report to > thread through it. Like other live properties with sensitive > information (such as DAV:acl or DAV:version-history), the server will > omit DAV:binding information for clients that are not permitted to see > it. Reports should be only used when parameters are required for the > request, and DAV:binding is not a parameterized request. RFC3253 counter example: DAV:version-tree report -- could have been replaced using a DAV:version-set report and the DAV:expand-property report Another one: why have the report DAV:locate-by-history if a DAV:version-controlled-resource-set property would offer the same information? I'm not convinced: the set of bindings of a resource is *not* a quality of the resource -- it's a quality of the collections that contain them. Computing all binds can be *very* expensive (for instance and AFAIK, in a plain old Unix filesystem you'll have to traverse the full namespace to find all bindings). From w3c-dist-auth-request@w3.org Fri Aug 2 08:43:11 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16980 for ; Fri, 2 Aug 2002 08:43:11 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA08862; Fri, 2 Aug 2002 08:42:57 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g72Cguw10854; Fri, 2 Aug 2002 08:42:56 -0400 (EDT) Resent-Date: Fri, 2 Aug 2002 08:42:56 -0400 (EDT) Resent-Message-Id: <200208021242.g72Cguw10854@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g72Cgr710834 for ; Fri, 2 Aug 2002 08:42:53 -0400 (EDT) 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 IAA08803 for ; Fri, 2 Aug 2002 08:42:53 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Fri, 02 Aug 2002 08:34:25 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 2 Aug 2002 08:42:22 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107BC503D@SUS-MA1IT01> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 2 Aug 2002 08:42:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6497 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: That warning is fine with me. There are a variety of ways in which the new resource could act differently, and that is one of them. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, August 02, 2002 3:31 AM To: Jason Crawford Cc: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities "COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH." I think *if* we say something like this we should warn that this may not produce a new resource that behaves the same under variant handling (because only one of possible multiple variants would be copied). -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Thursday, August 01, 2002 6:49 PM To: Jason Crawford Cc: Clemm, Geoff; w3c-dist-auth@w3c.org Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as resolved... Resolved: 8/1/02: COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH. - MOVE should maintain the integrity of the resource in that all live properties and behaviors should remain live and have the same semantics at the new location as at the old location. If there is any doubt "same" is defined according to the resource author's concept of "this resource". If you'd like this changed, just speak up. :-) J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Fri Aug 2 11:27:19 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23726 for ; Fri, 2 Aug 2002 11:27:19 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA25688; Fri, 2 Aug 2002 11:26:59 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g72FQu300674; Fri, 2 Aug 2002 11:26:56 -0400 (EDT) Resent-Date: Fri, 2 Aug 2002 11:26:56 -0400 (EDT) Resent-Message-Id: <200208021526.g72FQu300674@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g72FQt700650 for ; Fri, 2 Aug 2002 11:26:55 -0400 (EDT) Received: from e1.ny.us.ibm.com. (e1.ny.us.ibm.com [32.97.182.101]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA25674 for ; Fri, 2 Aug 2002 11:26:55 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com. (8.12.2/8.12.2) with ESMTP id g72FQHbW100050; Fri, 2 Aug 2002 11:26:17 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g72FQFIF027034; Fri, 2 Aug 2002 11:26:15 -0400 To: "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, 2 Aug 2002 11:22:35 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build M13TT_07122002 Pre-release 2|July 12, 2002) at 08/02/2002 11:26:15 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE69ADFC7F1828f9e8a93df938690918c0ABBE69ADFC7F182" Content-Disposition: inline Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6498 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --0__=0ABBE69ADFC7F1828f9e8a93df938690918c0ABBE69ADFC7F182 Content-type: text/plain; charset=US-ASCII > That warning is fine with me. There are a variety of ways in > which the new resource could act differently, and that is one of them. Fine with me also. :-) ------------------------------------------ Phone: 914-784-7569 --0__=0ABBE69ADFC7F1828f9e8a93df938690918c0ABBE69ADFC7F182 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> That warning is fine with me. There are a variety of ways in
> which the new resource could act differently, and that is one of them.

Fine with me also. :-)


------------------------------------------
Phone: 914-784-7569
--0__=0ABBE69ADFC7F1828f9e8a93df938690918c0ABBE69ADFC7F182-- From w3c-dist-auth-request@w3.org Sun Aug 4 14:13:50 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09938 for ; Sun, 4 Aug 2002 14:13:49 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA02216; Sun, 4 Aug 2002 14:13:21 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g74ICaP09141; Sun, 4 Aug 2002 14:12:36 -0400 (EDT) Resent-Date: Sun, 4 Aug 2002 14:12:36 -0400 (EDT) Resent-Message-Id: <200208041812.g74ICaP09141@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g74ICZ709121 for ; Sun, 4 Aug 2002 14:12:35 -0400 (EDT) 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 OAA02088 for ; Sun, 4 Aug 2002 14:12:34 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Sun, 04 Aug 2002 14:03:55 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 4 Aug 2002 14:11:58 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107BC52E9@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Sun, 4 Aug 2002 14:11:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6499 X-Loop: w3c-dist-auth@w3.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: Julian Reschke [mailto:julian.reschke@gmx.de] > Reports should be only used when parameters are required for the > request, and DAV:binding is not a parameterized request. RFC3253 counter example: DAV:version-tree report -- could have been replaced using a DAV:version-set report and the DAV:expand-property report The DAV:version-tree report requires additional parameters (in particular, the list of properties to be retrieved). It therefore must be a report, not a live property. It is true that the DAV:version-tree report could be handled by a DAV:expand-property report, but that doesn't affect the fact that the DAV:version-tree report requires additional parameters, which is why it is a report and not a live property. Another one: why have the report DAV:locate-by-history if a DAV:version-controlled-resource-set property would offer the same information? The DAV:locate-by-history report requires additional parameters (namely, the list of version history resources that are to be located in the folder identified by the request-URL). Therefore it cannot be a live property, but must be a report. I'm not convinced: the set of bindings of a resource is *not* a quality of the resource -- it's a quality of the collections that contain them. Computing all binds can be *very* expensive (for instance and AFAIK, in a plain old Unix filesystem you'll have to traverse the full namespace to find all bindings). I agree that bindings are part of the state of the collection, not part of the state of the resource, but there are many live properties that are used to report on relationships to other resources. There are also other live properties that are expensive to compute. But it is sufficient to require that such properties be explicitly requested (as is the case for all RFC-3253 properties), so that the client can control whether or not they want to pay the cost of this computation. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Aug 4 18:19:49 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13985 for ; Sun, 4 Aug 2002 18:19:48 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA27582; Sun, 4 Aug 2002 18:19:35 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g74MJWs18185; Sun, 4 Aug 2002 18:19:32 -0400 (EDT) Resent-Date: Sun, 4 Aug 2002 18:19:32 -0400 (EDT) Resent-Message-Id: <200208042219.g74MJWs18185@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g74MJV718150 for ; Sun, 4 Aug 2002 18:19:31 -0400 (EDT) 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 SAA27574 for ; Sun, 4 Aug 2002 18:19:30 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id PAA12675 for ; Sun, 4 Aug 2002 15:19:27 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Sun, 4 Aug 2002 15:17:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: FYI: WSE 2002 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6500 X-Loop: w3c-dist-auth@w3.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 FYI, members of this list might be interested in the 4th International Workshop on Web Site Evolution (WSE 2002), being held October 2, 2002, in Montreal, Canada. http://star.itc.it/wse2002/ - Jim From the Web page: The potential of the Web as a vehicle for offering a variety of services is becoming more apparent as Web sites evolve their contents from static information to more dynamic and interactive forms. A number of new standards and commercial products are emerging, offering a basis for developing Web-based services from dynamic composible resources, extending both the range and scope of services that can be made available through the Web. The goal of this one-day workshop is to bring together members of the Web design, software engineering, and information technology communities to discuss techniques for migrating to Web services. Architectural styles and tool support for service-based Web sites are currently quite diverse. Expertise in constructing service-based Web pages is quite limited, and experience accounts are lacking. The explosion of non-traditional computing platforms for browsing the Web, such as PDAs, WAP-enabled phones, and Internet appliances, is forcing Web professionals to rethink the separation of form from content and the range and scope of services offered via the Web. WSE 2002 will provide an opportunity for the exchange of information related to exciting new research and empirical results in areas including (but not limited to): * Migrating to Web services * Web quality determination and improvement through process and product control * Enhancing Web sites to make them more accessible, reliable, and usable * Analyzing and reverse-engineering Web site content and structure * Making Web site content available in multiple formats for multiple platforms * Applying traditional software engineering activities such as architecture, metrics, and testing to Web sites * Case studies of large-scale Web site reuse, reengineering, and evolution WSE 2002 is co-located with the IEEE International Conference on Software Maintenance (ICSM 2002). ICSM is the IEEE Computer Society's flagship event focused on the modernization of existing systems. ICSM 2002's theme of "maintaining distributed heterogeneous systems" nicely compliments WSE 2002's overall theme and goals. From w3c-dist-auth-request@w3.org Mon Aug 5 14:47:31 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26958 for ; Mon, 5 Aug 2002 14:47:30 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA31945; Mon, 5 Aug 2002 14:46:06 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g75IjeZ21189; Mon, 5 Aug 2002 14:45:40 -0400 (EDT) Resent-Date: Mon, 5 Aug 2002 14:45:40 -0400 (EDT) Resent-Message-Id: <200208051845.g75IjeZ21189@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g75Ijd721169 for ; Mon, 5 Aug 2002 14:45:39 -0400 (EDT) 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 OAA31861 for ; Mon, 5 Aug 2002 14:45:38 -0400 Received: (qmail 19101 invoked by uid 0); 5 Aug 2002 18:45:07 -0000 Received: from p3ee2481f.dip.t-dialin.net (HELO lisa) (62.226.72.31) by mail.gmx.net (mp016-rz3) with SMTP; 5 Aug 2002 18:45:07 -0000 From: "Julian Reschke" To: "WebDAV" Date: Mon, 5 Aug 2002 20:45:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: PROPFIND vs REPORT vs depth infinity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6501 X-Loop: w3c-dist-auth@w3.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, re: RFC2518 issue: PROPFIND_INFINITY. So the plan is that servers MAY reject PROPFIND with depth infinity, and the currently suggested return value is 403 (forbidden). Now what applies to PROPFIND should apply to REPORT as well, right? The ACL draft defines only reports with depth == 0, and requires 400 (bad request) otherwise. RFC3253 is silent about that issue, suggesting that servers may not reject the request. It would be nice if we could make this consistent before it's too late... Julian From w3c-dist-auth-request@w3.org Mon Aug 5 15:20:29 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28299 for ; Mon, 5 Aug 2002 15:20:28 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05619; Mon, 5 Aug 2002 15:20:17 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g75JKHT23667; Mon, 5 Aug 2002 15:20:17 -0400 (EDT) Resent-Date: Mon, 5 Aug 2002 15:20:17 -0400 (EDT) Resent-Message-Id: <200208051920.g75JKHT23667@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g75JKG723643 for ; Mon, 5 Aug 2002 15:20:16 -0400 (EDT) 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 PAA05616 for ; Mon, 5 Aug 2002 15:20:16 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 05 Aug 2002 15:11:39 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 5 Aug 2002 15:19:44 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107839146@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 5 Aug 2002 15:19:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PROPFIND vs REPORT vs depth infinity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6502 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: What do you have in mind for making this consistent? There are some reports in RFC-3253 that are usefully applied with Depth>0 (e.g. DAV:expand-property and DAV:version-tree). There are others that only make sense for Depth=0 (DAV:compare-baseline and DAV:merge-preview). So I agree that we can make the reports that only make sense for Depth=0 to say so explicitly, as does the ACL spec. Is that what you had in mind? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, August 05, 2002 2:45 PM To: WebDAV Subject: PROPFIND vs REPORT vs depth infinity Hi, re: RFC2518 issue: PROPFIND_INFINITY. So the plan is that servers MAY reject PROPFIND with depth infinity, and the currently suggested return value is 403 (forbidden). Now what applies to PROPFIND should apply to REPORT as well, right? The ACL draft defines only reports with depth == 0, and requires 400 (bad request) otherwise. RFC3253 is silent about that issue, suggesting that servers may not reject the request. It would be nice if we could make this consistent before it's too late... Julian From w3c-dist-auth-request@w3.org Mon Aug 5 15:36:36 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28895 for ; Mon, 5 Aug 2002 15:36:36 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA08443; Mon, 5 Aug 2002 15:35:23 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g75JZNs24320; Mon, 5 Aug 2002 15:35:23 -0400 (EDT) Resent-Date: Mon, 5 Aug 2002 15:35:23 -0400 (EDT) Resent-Message-Id: <200208051935.g75JZNs24320@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g75JZM724300 for ; Mon, 5 Aug 2002 15:35:22 -0400 (EDT) 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 PAA08436 for ; Mon, 5 Aug 2002 15:35:21 -0400 Received: (qmail 16594 invoked by uid 0); 5 Aug 2002 19:34:59 -0000 Received: from p3ee2481f.dip.t-dialin.net (HELO lisa) (62.226.72.31) by mail.gmx.net (mp003-rz3) with SMTP; 5 Aug 2002 19:34:59 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 5 Aug 2002 21:34:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839146@SUS-MA1IT01> Subject: RE: PROPFIND vs REPORT vs depth infinity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6503 X-Loop: w3c-dist-auth@w3.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 Sorry for not being clear. What I meant is that for the same reasons a server may want to reject PROPFINDs with depth infinity, it may want to reject REPORTs with depth infinity as well. In particular, I can use DAV:expand-property to simulate a PROPFIND/DAV:prop, so it doesn't seem to make sense to change RFC2518 to make PROPFIND/DAV:prop/depth-infinity optional, while requiring support for an equivalent REPORT (DAV:expand-property). Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, August 05, 2002 9:20 PM > To: WebDAV > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > > What do you have in mind for making this consistent? > > There are some reports in RFC-3253 that are usefully applied with > Depth>0 (e.g. DAV:expand-property and DAV:version-tree). There are > others that only make sense for Depth=0 (DAV:compare-baseline and > DAV:merge-preview). So I agree that we can make the reports that only > make sense for Depth=0 to say so explicitly, as does the ACL spec. > Is that what you had in mind? > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, August 05, 2002 2:45 PM > To: WebDAV > Subject: PROPFIND vs REPORT vs depth infinity > > > > Hi, > > re: RFC2518 issue: PROPFIND_INFINITY. > > So the plan is that servers MAY reject PROPFIND with depth > infinity, and the > currently suggested return value is 403 (forbidden). > > Now what applies to PROPFIND should apply to REPORT as well, right? > > The ACL draft defines only reports with depth == 0, and requires 400 (bad > request) otherwise. > > RFC3253 is silent about that issue, suggesting that servers may not reject > the request. > > It would be nice if we could make this consistent before it's too late... > > Julian > From w3c-dist-auth-request@w3.org Mon Aug 5 16:11:12 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00169 for ; Mon, 5 Aug 2002 16:11:12 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA13433; Mon, 5 Aug 2002 16:10:04 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g75K9xQ25772; Mon, 5 Aug 2002 16:09:59 -0400 (EDT) Resent-Date: Mon, 5 Aug 2002 16:09:59 -0400 (EDT) Resent-Message-Id: <200208052009.g75K9xQ25772@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g75K9w725748 for ; Mon, 5 Aug 2002 16:09:58 -0400 (EDT) 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 QAA13382 for ; Mon, 5 Aug 2002 16:09:58 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Mon, 05 Aug 2002 16:01:21 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 5 Aug 2002 16:09:27 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107839149@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Mon, 5 Aug 2002 16:09:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PROPFIND vs REPORT vs depth infinity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6504 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that if PROPFIND MAY refuse to process a Depth:infinity request, than it should also be the case that REPORT MAY refuse to process a Depth:infinity request. For REPORT, I'd also define a DAV:error value for this condition, so that a client can tell that it is non-support for Depth:Infinity that caused the failure. But note that I think it is fine for specific reports to return 400 (meaning that the report by definition does not allow the specified Depth), while other reports return 403 meaning that this implementation does not support it, even if it the report is defined for that Depth. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, August 05, 2002 3:35 PM To: Clemm, Geoff; WebDAV Subject: RE: PROPFIND vs REPORT vs depth infinity Sorry for not being clear. What I meant is that for the same reasons a server may want to reject PROPFINDs with depth infinity, it may want to reject REPORTs with depth infinity as well. In particular, I can use DAV:expand-property to simulate a PROPFIND/DAV:prop, so it doesn't seem to make sense to change RFC2518 to make PROPFIND/DAV:prop/depth-infinity optional, while requiring support for an equivalent REPORT (DAV:expand-property). Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, August 05, 2002 9:20 PM > To: WebDAV > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > > What do you have in mind for making this consistent? > > There are some reports in RFC-3253 that are usefully applied with > Depth>0 (e.g. DAV:expand-property and DAV:version-tree). There are > others that only make sense for Depth=0 (DAV:compare-baseline and > DAV:merge-preview). So I agree that we can make the reports that only > make sense for Depth=0 to say so explicitly, as does the ACL spec. > Is that what you had in mind? > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, August 05, 2002 2:45 PM > To: WebDAV > Subject: PROPFIND vs REPORT vs depth infinity > > > > Hi, > > re: RFC2518 issue: PROPFIND_INFINITY. > > So the plan is that servers MAY reject PROPFIND with depth > infinity, and the > currently suggested return value is 403 (forbidden). > > Now what applies to PROPFIND should apply to REPORT as well, right? > > The ACL draft defines only reports with depth == 0, and requires 400 (bad > request) otherwise. > > RFC3253 is silent about that issue, suggesting that servers may not reject > the request. > > It would be nice if we could make this consistent before it's too late... > > Julian > From w3c-dist-auth-request@w3.org Thu Aug 8 16:02:45 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25135 for ; Thu, 8 Aug 2002 16:02:44 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA09998; Thu, 8 Aug 2002 16:02:24 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g78K1vS04877; Thu, 8 Aug 2002 16:01:57 -0400 (EDT) Resent-Date: Thu, 8 Aug 2002 16:01:57 -0400 (EDT) Resent-Message-Id: <200208082001.g78K1vS04877@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g78K1u704857 for ; Thu, 8 Aug 2002 16:01:56 -0400 (EDT) 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 QAA09863 for ; Thu, 8 Aug 2002 16:01:55 -0400 Received: (qmail 26388 invoked by uid 0); 8 Aug 2002 20:01:24 -0000 Received: from p3ee24772.dip.t-dialin.net (HELO lisa) (62.226.71.114) by mail.gmx.net (mp001-rz3) with SMTP; 8 Aug 2002 20:01:24 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Thu, 8 Aug 2002 22:01:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107839149@SUS-MA1IT01> Importance: Normal Subject: RE: PROPFIND vs REPORT vs depth infinity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6505 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ok, so we have: - REPORT not defined for this depth --> 400 (bad request) - REPORT is defined, but server doesn't allow depth infinity --> 403 (forbidden). Should we define an error condition name for this situation and add that to the RFC3253 (proposal: "DAV:depth-infinity-allowed")? Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, August 05, 2002 10:09 PM > To: WebDAV > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > > I agree that if PROPFIND MAY refuse to process a Depth:infinity > request, than it should also be the case that REPORT MAY refuse > to process a Depth:infinity request. For REPORT, I'd also define > a DAV:error value for this condition, so that a client can tell > that it is non-support for Depth:Infinity that caused the failure. > > But note that I think it is fine for specific reports to return 400 > (meaning that the report by definition does not allow > the specified Depth), while other reports return 403 > meaning that this implementation > does not support it, even if it the report is defined for > that Depth. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, August 05, 2002 3:35 PM > To: Clemm, Geoff; WebDAV > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > Sorry for not being clear. > > What I meant is that for the same reasons a server may want to reject > PROPFINDs with depth infinity, it may want to reject REPORTs with depth > infinity as well. In particular, I can use DAV:expand-property to > simulate a > PROPFIND/DAV:prop, so it doesn't seem to make sense to change RFC2518 to > make PROPFIND/DAV:prop/depth-infinity optional, while requiring > support for > an equivalent REPORT (DAV:expand-property). > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, August 05, 2002 9:20 PM > > To: WebDAV > > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > > > > > > What do you have in mind for making this consistent? > > > > There are some reports in RFC-3253 that are usefully applied with > > Depth>0 (e.g. DAV:expand-property and DAV:version-tree). There are > > others that only make sense for Depth=0 (DAV:compare-baseline and > > DAV:merge-preview). So I agree that we can make the reports that only > > make sense for Depth=0 to say so explicitly, as does the ACL spec. > > Is that what you had in mind? > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Monday, August 05, 2002 2:45 PM > > To: WebDAV > > Subject: PROPFIND vs REPORT vs depth infinity > > > > > > > > Hi, > > > > re: RFC2518 issue: PROPFIND_INFINITY. > > > > So the plan is that servers MAY reject PROPFIND with depth > > infinity, and the > > currently suggested return value is 403 (forbidden). > > > > Now what applies to PROPFIND should apply to REPORT as well, right? > > > > The ACL draft defines only reports with depth == 0, and > requires 400 (bad > > request) otherwise. > > > > RFC3253 is silent about that issue, suggesting that servers may > not reject > > the request. > > > > It would be nice if we could make this consistent before it's > too late... > > > > Julian > > > From w3c-dist-auth-request@w3.org Thu Aug 8 16:10:45 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25360 for ; Thu, 8 Aug 2002 16:10:45 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA12343; Thu, 8 Aug 2002 16:10:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g78KARq06655; Thu, 8 Aug 2002 16:10:27 -0400 (EDT) Resent-Date: Thu, 8 Aug 2002 16:10:27 -0400 (EDT) Resent-Message-Id: <200208082010.g78KARq06655@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g78KAQ706635 for ; Thu, 8 Aug 2002 16:10:26 -0400 (EDT) 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 QAA12333 for ; Thu, 8 Aug 2002 16:10:26 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31.rational.com with InterScan Messaging Security Suite for SMTP; Thu, 08 Aug 2002 16:01:33 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 8 Aug 2002 16:09:46 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B107839176@SUS-MA1IT01> From: "Clemm, Geoff" To: WebDAV Date: Thu, 8 Aug 2002 16:09:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PROPFIND vs REPORT vs depth infinity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6506 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: That sounds sensible to me. If there are no objections, I'll add this as the resolution to this issue to the RFC 3253 Errata/Issue list. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, August 08, 2002 4:01 PM To: Clemm, Geoff; WebDAV Subject: RE: PROPFIND vs REPORT vs depth infinity Ok, so we have: - REPORT not defined for this depth --> 400 (bad request) - REPORT is defined, but server doesn't allow depth infinity --> 403 (forbidden). Should we define an error condition name for this situation and add that to the RFC3253 (proposal: "DAV:depth-infinity-allowed")? Julian > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, August 05, 2002 10:09 PM > To: WebDAV > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > > I agree that if PROPFIND MAY refuse to process a Depth:infinity > request, than it should also be the case that REPORT MAY refuse > to process a Depth:infinity request. For REPORT, I'd also define > a DAV:error value for this condition, so that a client can tell > that it is non-support for Depth:Infinity that caused the failure. > > But note that I think it is fine for specific reports to return 400 > (meaning that the report by definition does not allow > the specified Depth), while other reports return 403 > meaning that this implementation > does not support it, even if it the report is defined for > that Depth. > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, August 05, 2002 3:35 PM > To: Clemm, Geoff; WebDAV > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > Sorry for not being clear. > > What I meant is that for the same reasons a server may want to reject > PROPFINDs with depth infinity, it may want to reject REPORTs with depth > infinity as well. In particular, I can use DAV:expand-property to > simulate a > PROPFIND/DAV:prop, so it doesn't seem to make sense to change RFC2518 to > make PROPFIND/DAV:prop/depth-infinity optional, while requiring > support for > an equivalent REPORT (DAV:expand-property). > > Julian > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, August 05, 2002 9:20 PM > > To: WebDAV > > Subject: RE: PROPFIND vs REPORT vs depth infinity > > > > > > > > What do you have in mind for making this consistent? > > > > There are some reports in RFC-3253 that are usefully applied with > > Depth>0 (e.g. DAV:expand-property and DAV:version-tree). There are > > others that only make sense for Depth=0 (DAV:compare-baseline and > > DAV:merge-preview). So I agree that we can make the reports that only > > make sense for Depth=0 to say so explicitly, as does the ACL spec. > > Is that what you had in mind? > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Monday, August 05, 2002 2:45 PM > > To: WebDAV > > Subject: PROPFIND vs REPORT vs depth infinity > > > > > > > > Hi, > > > > re: RFC2518 issue: PROPFIND_INFINITY. > > > > So the plan is that servers MAY reject PROPFIND with depth > > infinity, and the > > currently suggested return value is 403 (forbidden). > > > > Now what applies to PROPFIND should apply to REPORT as well, right? > > > > The ACL draft defines only reports with depth == 0, and > requires 400 (bad > > request) otherwise. > > > > RFC3253 is silent about that issue, suggesting that servers may > not reject > > the request. > > > > It would be nice if we could make this consistent before it's > too late... > > > > Julian > > > From w3c-dist-auth-request@w3.org Fri Aug 9 14:07:52 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05590 for ; Fri, 9 Aug 2002 14:07:52 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA21879; Fri, 9 Aug 2002 14:07:38 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g79I6hq22152; Fri, 9 Aug 2002 14:06:43 -0400 (EDT) Resent-Date: Fri, 9 Aug 2002 14:06:43 -0400 (EDT) Resent-Message-Id: <200208091806.g79I6hq22152@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g79I6g722132 for ; Fri, 9 Aug 2002 14:06:42 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA21567 for ; Fri, 9 Aug 2002 14:06:41 -0400 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id g79I61g18188 for ; Fri, 9 Aug 2002 11:06:04 -0700 (PDT) Message-ID: <3D540489.3080204@cse.ucsc.edu> Date: Fri, 09 Aug 2002 11:06:01 -0700 From: Elias Sinderson Reply-To: WebDAV User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020518 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: WebDAV References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: PROPFIND vs REPORT vs depth infinity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6507 X-Loop: w3c-dist-auth@w3.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 proposal makes sense to me, as does the error condition name. Elias Julian Reschke wrote: >- REPORT not defined for this depth --> 400 (bad request) > >- REPORT is defined, but server doesn't allow depth infinity --> 403 >(forbidden). Should we define an error condition name for this situation and >add that to the RFC3253 (proposal: "DAV:depth-infinity-allowed")? > From w3c-dist-auth-request@w3.org Fri Aug 9 15:12:47 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07763 for ; Fri, 9 Aug 2002 15:12:47 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA02949; Fri, 9 Aug 2002 15:12:37 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g79JCZb29190; Fri, 9 Aug 2002 15:12:35 -0400 (EDT) Resent-Date: Fri, 9 Aug 2002 15:12:35 -0400 (EDT) Resent-Message-Id: <200208091912.g79JCZb29190@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g79JCY729166 for ; Fri, 9 Aug 2002 15:12:34 -0400 (EDT) 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 PAA02937 for ; Fri, 9 Aug 2002 15:12:33 -0400 Received: (qmail 4044 invoked by uid 0); 9 Aug 2002 19:12:02 -0000 Received: from pd950c3ab.dip.t-dialin.net (HELO lisa) (217.80.195.171) by mail.gmx.net (mp014-rz3) with SMTP; 9 Aug 2002 19:12:02 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Fri, 9 Aug 2002 21:12:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B107BC52E9@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6508 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, August 04, 2002 8:12 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Bindings > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > Reports should be only used when parameters are required for the > > request, and DAV:binding is not a parameterized request. > > RFC3253 counter example: DAV:version-tree report -- could have been > replaced using a DAV:version-set report and the DAV:expand-property > report > > The DAV:version-tree report requires additional parameters (in > particular, the list of properties to be retrieved). It therefore > must be a report, not a live property. It is true that the > DAV:version-tree report could be handled by a DAV:expand-property > report, but that doesn't affect the fact that the DAV:version-tree > report requires additional parameters, which is why it is a report and > not a live property. Wel, it requires additional parameters *because* it's a report. It wouldn't, if a live property would have been chosen instead... > Another one: why have the report DAV:locate-by-history if a > DAV:version-controlled-resource-set property would offer the same > information? > > The DAV:locate-by-history report requires additional parameters > (namely, the list of version history resources that are to be located > in the folder identified by the request-URL). Therefore it cannot be > a live property, but must be a report. This is just because the marshalling was defined to specifically to lookup by by multiple VHRs (by the way: what's the use case for that?). My point being -- the border between live properties and REPORTs isn't nearly as well defined as you say. > ... From w3c-dist-auth-request@w3.org Fri Aug 9 17:17:14 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11483 for ; Fri, 9 Aug 2002 17:17:14 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA29573; Fri, 9 Aug 2002 17:16:55 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g79LGnN22394; Fri, 9 Aug 2002 17:16:49 -0400 (EDT) Resent-Date: Fri, 9 Aug 2002 17:16:49 -0400 (EDT) Resent-Message-Id: <200208092116.g79LGnN22394@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g79LGm722374 for ; Fri, 9 Aug 2002 17:16:48 -0400 (EDT) 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 RAA29557 for ; Fri, 9 Aug 2002 17:16:48 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by sus-ma1it31 with InterScan Messaging Security Suite; Fri, 09 Aug 2002 17:08:02 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 9 Aug 2002 17:16:17 -0400 Message-ID: <3906C56A7BD1F54593344C05BD1374B10783918F@SUS-MA1IT01> From: "Clemm, Geoff" To: "'Webdav WG (E-mail)'" Date: Fri, 9 Aug 2002 17:16:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6509 X-Loop: w3c-dist-auth@w3.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: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > Reports should be only used when parameters are required for the > > request, and DAV:binding is not a parameterized request. > > RFC3253 counter example: DAV:version-tree report -- could have been > replaced using a DAV:version-set report and the DAV:expand-property > report > > The DAV:version-tree report requires additional parameters (in > particular, the list of properties to be retrieved). Wel, it requires additional parameters *because* it's a report. It wouldn't, if a live property would have been chosen instead... The fact that a version-tree request requires more than a URL (i.e. it also needs the list of properties to be retrieved) is not affected by how we marshall the request. How would you marshall as a PROPFIND a request that wants the MYPROP:foo and MYPROP:bar properties of every version in the version tree? You have to put the "MYPROP:foo" and "MYPROP:bar" information somewhere, and there is nowhere to put it in a standard PROPFIND request. > Another one: why have the report DAV:locate-by-history if a > DAV:version-controlled-resource-set property would offer the same > information? > > The DAV:locate-by-history report requires additional parameters > (namely, the list of version history resources that are to be located > in the folder identified by the request-URL). Therefore it cannot be > a live property, but must be a report. This is just because the marshalling was defined to specifically to lookup by by multiple VHRs (by the way: what's the use case for that?). No, this is just because you need at least two values: the URL for the folder in which to look for the VCR, and the URL for the version history that you are looking for. The fact that you are allowed to look for several version histories in one request is irrelevant (but since you asked, this is usually an expensive operation which can be optimized if the server can use one pass to look for all the version histories that you are interested in). My point being -- the border between live properties and REPORTs isn't nearly as well defined as you say. Simple well-defined rule: If you only need to specify a URL and a (constant, standard) property-name in the request, it is a live property. If you need more than that, it is a report. Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Aug 10 04:27:47 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03122 for ; Sat, 10 Aug 2002 04:27:46 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA26036; Sat, 10 Aug 2002 04:27:07 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7A8QFt10636; Sat, 10 Aug 2002 04:26:15 -0400 (EDT) Resent-Date: Sat, 10 Aug 2002 04:26:15 -0400 (EDT) Resent-Message-Id: <200208100826.g7A8QFt10636@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7A8QEM10616 for ; Sat, 10 Aug 2002 04:26:14 -0400 (EDT) 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 EAA25920 for ; Sat, 10 Aug 2002 04:26:13 -0400 Received: (qmail 2516 invoked by uid 0); 10 Aug 2002 08:25:42 -0000 Received: from pd950c3ab.dip.t-dialin.net (HELO lisa) (217.80.195.171) by mail.gmx.net (mp016-rz3) with SMTP; 10 Aug 2002 08:25:42 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG \(E-mail\)'" Date: Sat, 10 Aug 2002 10:25:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10783918F@SUS-MA1IT01> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: RE: Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6510 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, August 09, 2002 11:16 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Bindings > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Clemm, Geoff > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > Reports should be only used when parameters are required for the > > > request, and DAV:binding is not a parameterized request. > > > > RFC3253 counter example: DAV:version-tree report -- could > have been > > replaced using a DAV:version-set report and the > DAV:expand-property > > report > > > > The DAV:version-tree report requires additional parameters (in > > particular, the list of properties to be retrieved). > > Wel, it requires additional parameters *because* it's a report. It > wouldn't, if a live property would have been chosen instead... > > The fact that a version-tree request requires more than a URL (i.e. it > also needs the list of properties to be retrieved) is not affected by > how we marshall the request. How would you marshall as a PROPFIND a > request that wants the MYPROP:foo and MYPROP:bar properties of every > version in the version tree? You have to put the "MYPROP:foo" and > "MYPROP:bar" information somewhere, and there is nowhere to put it in > a standard PROPFIND request. I wouldn't marshall it as PROPFIND. I would use the DAV:expand-property REPORT. > > Another one: why have the report DAV:locate-by-history if a > > DAV:version-controlled-resource-set property would offer the same > > information? > > > > The DAV:locate-by-history report requires additional parameters > > (namely, the list of version history resources that are to be located > > in the folder identified by the request-URL). Therefore it cannot be > > a live property, but must be a report. > > This is just because the marshalling was defined to specifically to > lookup > by by multiple VHRs (by the way: what's the use case for that?). > > No, this is just because you need at least two values: the URL for the > folder in which to look for the VCR, and the URL for the version > history that you are looking for. The fact that you are allowed to OK, so why isn't it good enough to search for *all* VCRs (no matter which collection they are in)? > look for several version histories in one request is irrelevant (but > since you asked, this is usually an expensive operation which can be > optimized if the server can use one pass to look for all the version > histories that you are interested in). > > My point being -- the border between live properties and REPORTs > isn't nearly as well defined as you say. > > Simple well-defined rule: If you only need to specify a URL and a > (constant, standard) property-name in the request, it is a live > property. If you need more than that, it is a report. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Wed Aug 14 09:43:18 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08864 for ; Wed, 14 Aug 2002 09:43:18 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA30177; Wed, 14 Aug 2002 09:42:49 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7EDgEt15405; Wed, 14 Aug 2002 09:42:14 -0400 (EDT) Resent-Date: Wed, 14 Aug 2002 09:42:14 -0400 (EDT) Resent-Message-Id: <200208141342.g7EDgEt15405@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7EDgCM15385 for ; Wed, 14 Aug 2002 09:42:12 -0400 (EDT) Received: from gcsu.edu (vir.gcsu.edu [168.16.214.18]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA30017 for ; Wed, 14 Aug 2002 09:42:12 -0400 Received: by gcsu.edu; id JAA26527; Wed, 14 Aug 2002 09:44:14 -0400 (EDT) Received: from sleepy.gcsu.edu(168.16.213.98) by vir.gcsu.edu via csmap (V4.1) id srcAAA2GaWZZ; Wed, 14 Aug 02 09:44:14 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 14 Aug 2002 09:42:09 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: launching a WebDAV client via HTML Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6511 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Are there any current or projected protocols that would enable one to create an HTML link to a WebDAV enabled site? I have in mind an analog to the mailto: tag. -- ===================================================================== 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 Wed Aug 14 22:58:11 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02227 for ; Wed, 14 Aug 2002 22:58:11 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA12856; Wed, 14 Aug 2002 22:57:12 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7F2v6D15841; Wed, 14 Aug 2002 22:57:06 -0400 (EDT) Resent-Date: Wed, 14 Aug 2002 22:57:06 -0400 (EDT) Resent-Message-Id: <200208150257.g7F2v6D15841@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7F2v5M15817 for ; Wed, 14 Aug 2002 22:57:05 -0400 (EDT) Received: from ns.xn.com.au (ns.xn.com.au [203.89.254.34]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA12847 for ; Wed, 14 Aug 2002 22:57:03 -0400 Received: (qmail 5753 invoked from network); 15 Aug 2002 03:34:27 -0000 Received: from cpe-203-51-130-2.vic.bigpond.net.au (HELO xn.com.au) (203.51.130.2) by ns.xn.com.au with SMTP; 15 Aug 2002 03:34:27 -0000 Message-ID: <3D5B131C.70405@xn.com.au> Date: Thu, 15 Aug 2002 12:34:04 +1000 From: Jason User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Lowney CC: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: launching a WebDAV client via HTML Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6512 X-Loop: w3c-dist-auth@w3.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 Of course you can create a GET type link, if you have the URL for the resource you want to link to. But it sounds like you want to launch a web dav client to look at the site? There is a proprietary microsoft way ie Internet Explorer 5 (which i haven't tested). See http://msdn.microsoft.com/workshop/author/behaviors/overview/webfolder.asp cheers, Jason Frank Lowney wrote: > > Are there any current or projected protocols that would enable one to > create an HTML link to a WebDAV enabled site? I have in mind an analog > to the mailto: tag. Frank Lowney wrote: > > Are there any current or projected protocols that would enable one to > create an HTML link to a WebDAV enabled site? I have in mind an analog > to the mailto: tag. From w3c-dist-auth-request@w3.org Mon Aug 19 17:28:49 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16246 for ; Mon, 19 Aug 2002 17:28:49 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA08874; Mon, 19 Aug 2002 17:28:27 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7JLRd400080; Mon, 19 Aug 2002 17:27:39 -0400 (EDT) Resent-Date: Mon, 19 Aug 2002 17:27:39 -0400 (EDT) Resent-Message-Id: <200208192127.g7JLRd400080@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7JLRbv00058 for ; Mon, 19 Aug 2002 17:27:37 -0400 (EDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA08707 for ; Mon, 19 Aug 2002 17:27:37 -0400 Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g7JLTQWL026306 for ; Mon, 19 Aug 2002 14:29:26 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-1.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g7JLRbuE014088 for ; Mon, 19 Aug 2002 14:27:37 -0700 (PDT) Received: from dan.local.brotsky.com ([130.248.62.34]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id H140X100.SK5 for ; Mon, 19 Aug 2002 14:27:01 -0700 Date: Mon, 19 Aug 2002 14:27:00 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Dan Brotsky To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <6584FB7C-B3BA-11D6-8317-0003931036B4@adobe.com> X-Mailer: Apple Mail (2.482) Subject: Re: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6513 X-Loop: w3c-dist-auth@w3.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 Thursday, August 1, 2002, at 09:49 AM, Jason Crawford wrote: > Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as > resolved... Sorry to react so late to this; I've been on sabbatical. > Resolved: 8/1/02: COPY should do the equivalent of a GET/PROPFIND > followed by PUT/PROPPATCH. - MOVE should maintain the integrity of the > resource in that all live properties and behaviors should remain live > and have the same semantics at the new location as at the old location. > If there is any doubt "same" is defined according to the resource > author's concept of "this resource". I'm not saying I necessarily disagree, but I'm worried by the fact that this definition distinguishes between COPY and MOVE in a way that's quite different from what many other (well-implemented) specs do. Consider the following: 1. Many specs define MOVE as the atomic equivalent of COPY followed by DELETE. Wait a minute, actually 2518 does too! Wouldn't this "clarification" break this? 2. (Separate but related issue; don't think it's on the issue list.) There is no reason to *require* COPY to create a *new* resource; in fact, that's quite a problem for servers that implement copy-on-write semantics. I believe the key sentences in the current RFC are: Subsequent alterations to the destination resource will not modify the source resource. Subsequent alterations to the source resource will not modify the destination resource. which of course there are many ways to implement. 3. As others have pointed out, a single GET/PROPFIND followed by a single PUT/PROPPATCH is very unlikely to do a good copy. This is exactly why we have a separate method for COPY in the first place. It seems to me that the best clarification we could provide about both COPY and MOVE has to do with servers being able to say whether they own the destination resource and thus can guarantee the kinds of "property preservation" clients are hoping for. That is, there seem to me to be two key cases: Case 1: Both source and destination URLs/resources are controlled by the same "server semantics/process," and thus the source server can do a COPY by associating a resource with the destination URL that behaves exactly the same as the source resource under all variant forms of GET/PROPFIND (modulo locks not being copied and the location being different). In this case MOVE is, in fact, indistinguishable to WebDAV clients from a successful COPY followed by a successful DELETE. (Although perhaps delta-V clients might be able to distinguish...) Case 2: The source and destination resources are controlled by the same "server semantics/process," and thus neither can do better than GET/PUT PROPFIND/PROPPATCH. I don't think we should spend a lot of time trying to put requirements on what to do in Case 2, especially since there's no reason for a client to think that doing the COPY is going to produce results that are either better or more efficient than just doing the four roundtrips! Instead I think we should try to clarify the requirements on Case 1 and we should add a way for servers to either say in advance or say after the fact (or both) which kind of COPY will/did happen. dan From w3c-dist-auth-request@w3.org Mon Aug 19 18:24:33 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17118 for ; Mon, 19 Aug 2002 18:24:33 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA22397; Mon, 19 Aug 2002 18:24:32 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7JMOL511491; Mon, 19 Aug 2002 18:24:21 -0400 (EDT) Resent-Date: Mon, 19 Aug 2002 18:24:21 -0400 (EDT) Resent-Message-Id: <200208192224.g7JMOL511491@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7JMOJv11467 for ; Mon, 19 Aug 2002 18:24:19 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA22284 for ; Mon, 19 Aug 2002 18:24:19 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 19 Aug 2002 18:23:39 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.208]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Mon, 19 Aug 2002 18:23:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Aug 2002 18:23:34 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D91E@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: New RFC2518bis draft, COPY / MOVE of live properities Thread-Index: AcJHx2pRLDjczqZhTZOkE4bRMATaCQAB0q+w From: "Lisa Dusseault" To: "Dan Brotsky" , X-OriginalArrivalTime: 19 Aug 2002 22:23:39.0148 (UTC) FILETIME=[1128BCC0:01C247CF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g7JMOJv11467 Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6514 X-Loop: w3c-dist-auth@w3.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 > Case 1: Both source and destination URLs/resources are controlled by the > same "server semantics/process," and thus the source server can do a > COPY by associating a resource with the destination URL that behaves > exactly the same as the source resource under all variant forms of > GET/PROPFIND (modulo locks not being copied and the location being > different). In this case MOVE is, in fact, indistinguishable to WebDAV > clients from a successful COPY followed by a successful DELETE. > (Although perhaps delta-V clients might be able to distinguish...) Not only deltaV clients may be able to distinguish, but ACL clients could. For example, in Xythos WFS, when a file is copied the server initializes the ACLs like a new file. On the other hand when a file is moved, the server copies the ACLs intact. Xythos WFS also tracks access logs on files, and when a file is moved we want to keep the access logs on it, but when it's copied we don't want to duplicate the access logs, just keep the access logs for the original. Overall, the new distinction between MOVE and COPY seems more often useful than problematic. Lisa From w3c-dist-auth-request@w3.org Mon Aug 19 19:56:07 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18325 for ; Mon, 19 Aug 2002 19:56:07 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA02080; Mon, 19 Aug 2002 19:56:06 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7JNto515996; Mon, 19 Aug 2002 19:55:50 -0400 (EDT) Resent-Date: Mon, 19 Aug 2002 19:55:50 -0400 (EDT) Resent-Message-Id: <200208192355.g7JNto515996@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7JNtmv15976 for ; Mon, 19 Aug 2002 19:55:48 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA02015 for ; Mon, 19 Aug 2002 19:55:48 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7JNtCha292644; Mon, 19 Aug 2002 19:55:12 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7JNt9qr026744; Mon, 19 Aug 2002 19:55:09 -0400 To: Dan Brotsky Cc: w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Mon, 19 Aug 2002 19:47:35 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_M14_08012002 Release Candidate|August 01, 2002) at 08/19/2002 19:55:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6515 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Dan, I've written a long answer to your posting, but I think I'll just send a short one. I tend to agree with Lisa. The way we've specified it now seems like the best we're going to do right now. COPY creates a new resource that is modeled on the source on a "best effort' basis whereas MOVE simply changes the URL at which we access a resource. And we've chosen to suggest that COPY (by default) just do the equivalent of of GET/PUT prop FIND/PATCH. I do see value in what you say at the end of your note. There might be value in a COPY'ing server to state how it treated the liveness of properties it just copied. Similarly it might be nice for a client to be able to point to a resource and ask a server what liveness constraints it's trying to maintain on various properties. But didn't we just remove the keep-alive feature? Apparently this wasn't used. So I'm hesitant to spend time working on liveness management features right now. Maybe later. I don't think what we're currently proposing closes the door on this. J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Tue Aug 20 06:35:19 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09997 for ; Tue, 20 Aug 2002 06:35:18 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA20728; Tue, 20 Aug 2002 06:35:22 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KAZGn23594; Tue, 20 Aug 2002 06:35:16 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 06:35:16 -0400 (EDT) Resent-Message-Id: <200208201035.g7KAZGn23594@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KAZFv23574 for ; Tue, 20 Aug 2002 06:35:15 -0400 (EDT) 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 GAA20713 for ; Tue, 20 Aug 2002 06:35:14 -0400 Received: (qmail 11907 invoked by uid 0); 20 Aug 2002 10:34:43 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp014-rz3) with SMTP; 20 Aug 2002 10:34:42 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Dan Brotsky" Cc: Date: Tue, 20 Aug 2002 12:34:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6516 X-Loop: w3c-dist-auth@w3.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 do see value in what you say at the end of your note. There might be > value in > a COPY'ing server to state how it treated the liveness of properties it > just copied. > Similarly it might be nice for a client to be able to point to a resource > and ask a server what liveness constraints it's trying to maintain on > various > properties. But didn't we just remove the keep-alive feature? Apparently > this > wasn't used. So I'm hesitant to spend time working on liveness management > features right now. Maybe later. I don't think what we're currently > proposing > closes the door on this. (agreed) From w3c-dist-auth-request@w3.org Tue Aug 20 06:42:59 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10160 for ; Tue, 20 Aug 2002 06:42:59 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA22542; Tue, 20 Aug 2002 06:43:06 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KAh5125564; Tue, 20 Aug 2002 06:43:05 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 06:43:05 -0400 (EDT) Resent-Message-Id: <200208201043.g7KAh5125564@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KAh4v25544 for ; Tue, 20 Aug 2002 06:43:04 -0400 (EDT) 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 GAA22533 for ; Tue, 20 Aug 2002 06:43:03 -0400 Received: (qmail 30728 invoked by uid 0); 20 Aug 2002 10:42:33 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 20 Aug 2002 10:42:33 -0000 From: "Julian Reschke" To: "Dan Brotsky" , Date: Tue, 20 Aug 2002 12:42:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <6584FB7C-B3BA-11D6-8317-0003931036B4@adobe.com> Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6517 X-Loop: w3c-dist-auth@w3.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 Dan Brotsky > Sent: Monday, August 19, 2002 11:27 PM > To: w3c-dist-auth@w3c.org > Subject: Re: New RFC2518bis draft, COPY / MOVE of live properities > > > > On Thursday, August 1, 2002, at 09:49 AM, Jason Crawford wrote: > > Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as > > resolved... > > Sorry to react so late to this; I've been on sabbatical. > > > Resolved: 8/1/02: COPY should do the equivalent of a GET/PROPFIND > > followed by PUT/PROPPATCH. - MOVE should maintain the integrity of the > > resource in that all live properties and behaviors should remain live > > and have the same semantics at the new location as at the old location. > > If there is any doubt "same" is defined according to the resource > > author's concept of "this resource". > > I'm not saying I necessarily disagree, but I'm worried by the fact that > this definition distinguishes between COPY and MOVE in a way that's > quite different from what many other (well-implemented) specs do. > Consider the following: > > 1. Many specs define MOVE as the atomic equivalent of COPY followed by > DELETE. Wait a minute, actually 2518 does too! Wouldn't this > "clarification" break this? Yes. > 2. (Separate but related issue; don't think it's on the issue list.) > There is no reason to *require* COPY to create a *new* resource; in > fact, that's quite a problem for servers that implement copy-on-write > semantics. I believe the key sentences in the current RFC are: > > Subsequent alterations to the destination resource will not modify > the source resource. Subsequent alterations to the source resource > will not modify the destination resource. > > which of course there are many ways to implement. Yes, but that's an implementation detail. Even if you implement the copy as copy-on-write, for the *client* it will be a new resource nevertheless. > ... From w3c-dist-auth-request@w3.org Tue Aug 20 16:47:53 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26225 for ; Tue, 20 Aug 2002 16:47:53 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA19236; Tue, 20 Aug 2002 16:47:57 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KKlZY13593; Tue, 20 Aug 2002 16:47:35 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 16:47:35 -0400 (EDT) Resent-Message-Id: <200208202047.g7KKlZY13593@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KKlYv13569 for ; Tue, 20 Aug 2002 16:47:34 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA19190 for ; Tue, 20 Aug 2002 16:47:34 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 20 Aug 2002 16:46:58 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([209.225.56.53]) by in002.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 20 Aug 2002 16:46:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Aug 2002 16:46:56 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA601736D924@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: IPv6 support in WebDAV and HTTP Thread-Index: AcJIitXMoWA+p1UzSVinOxkO5QwIWQ== From: "Lisa Dusseault" To: X-OriginalArrivalTime: 20 Aug 2002 20:46:57.0266 (UTC) FILETIME=[B9618D20:01C2488A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g7KKlYv13569 Subject: IPv6 support in WebDAV and HTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6518 X-Loop: w3c-dist-auth@w3.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 WebDAV (RFC2518) imports its URL scheme definition from HTTP 1.1 (RFC2396). HTTP says: "The host is a domain name of a network host, or its IPv4 address as a set of four decimal digit groups separated by ".". Literal IPv6 addresses are not supported." hostport = host [ ":" port ] host = hostname | IPv4address Does that mean that WebDAV *cannot* support IPv6 addresses? Until I started looking into this, I naively assumed that WebDAV already did support IPv6 addresses, or could easily. lisa From w3c-dist-auth-request@w3.org Tue Aug 20 18:27:58 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29128 for ; Tue, 20 Aug 2002 18:27:58 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA07769; Tue, 20 Aug 2002 18:27:59 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KMRrY23834; Tue, 20 Aug 2002 18:27:53 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 18:27:53 -0400 (EDT) Resent-Message-Id: <200208202227.g7KMRrY23834@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KMRpv23814 for ; Tue, 20 Aug 2002 18:27:51 -0400 (EDT) Received: from localhost.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 SAA07705 for ; Tue, 20 Aug 2002 18:27:50 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g7KM8sAq007032; Tue, 20 Aug 2002 15:08:54 -0700 (PDT) Date: Tue, 20 Aug 2002 15:08:53 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: "Lisa Dusseault" From: "Roy T. Fielding" In-Reply-To: <27889B08CAEC7049B68FAD8717BA601736D924@ATL1VEXC006.usdom004.tco.tc> Message-Id: <69F82EB0-B489-11D6-868F-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: IPv6 support in WebDAV and HTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6519 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > WebDAV (RFC2518) imports its URL scheme definition from HTTP 1.1 > (RFC2396). HTTP says: > > "The host is a domain name of a network host, or its IPv4 address as > a > set of four decimal digit groups separated by ".". Literal IPv6 > addresses are not supported." > > hostport = host [ ":" port ] > host = hostname | IPv4address > > Does that mean that WebDAV *cannot* support IPv6 addresses? Until I > started looking into this, I naively assumed that WebDAV already did > support IPv6 addresses, or could easily. If WebDAV imports by reference (not cut-n-paste), then its reference is updated by the RFCs that update 2396, one of which defines the literal IPv6 address. ....Roy From w3c-dist-auth-request@w3.org Tue Aug 20 18:41:07 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29334 for ; Tue, 20 Aug 2002 18:41:07 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA10547; Tue, 20 Aug 2002 18:41:16 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KMfBB24479; Tue, 20 Aug 2002 18:41:11 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 18:41:11 -0400 (EDT) Resent-Message-Id: <200208202241.g7KMfBB24479@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KMfBv24459 for ; Tue, 20 Aug 2002 18:41:11 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA10502 for ; Tue, 20 Aug 2002 18:41:10 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 20 Aug 2002 18:40:11 -0400 (Eastern Daylight Time) Received: from ATL1VEXC006.usdom004.tco.tc ([10.158.7.208]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Tue, 20 Aug 2002 18:40:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Aug 2002 18:40:05 -0400 Message-ID: <27889B08CAEC7049B68FAD8717BA6017371BD9@ATL1VEXC006.usdom004.tco.tc> Thread-Topic: IPv6 support in WebDAV and HTTP Thread-Index: AcJImM/oiT5wigMJSTqRNAa6hc+CBgAASQXA From: "Lisa Dusseault" To: "Roy T. Fielding" Cc: X-OriginalArrivalTime: 20 Aug 2002 22:40:10.0259 (UTC) FILETIME=[8A520630:01C2489A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g7KMfBv24459 Subject: RE: IPv6 support in WebDAV and HTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6520 X-Loop: w3c-dist-auth@w3.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 RFC2616 says: "http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]" I can't find a definition of the host part. It does however say "The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24])." So: - Does the wording in RFC2616 require support for IPv6 for HTTP servers? Or does it merely skirt the issue? - Does anybody have any idea how HTTP servers and clients handle IPv6 addresses in practice? I assume RFC2518bis should update its references to RFC2396 to RFC2616, which results in removing the restriction to IPv4 addresses only. Lisa > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@apache.org] > Sent: Tuesday, August 20, 2002 3:09 PM > To: Lisa Dusseault > Cc: w3c-dist-auth@w3c.org > Subject: Re: IPv6 support in WebDAV and HTTP > > > WebDAV (RFC2518) imports its URL scheme definition from HTTP 1.1 > > (RFC2396). HTTP says: > > > > "The host is a domain name of a network host, or its IPv4 address as > > a > > set of four decimal digit groups separated by ".". Literal IPv6 > > addresses are not supported." > > > > hostport = host [ ":" port ] > > host = hostname | IPv4address > > > > Does that mean that WebDAV *cannot* support IPv6 addresses? Until I > > started looking into this, I naively assumed that WebDAV already did > > support IPv6 addresses, or could easily. > > If WebDAV imports by reference (not cut-n-paste), then its reference > is updated by the RFCs that update 2396, one of which defines the > literal IPv6 address. > > ....Roy From w3c-dist-auth-request@w3.org Tue Aug 20 18:59:57 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29673 for ; Tue, 20 Aug 2002 18:59:57 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA13191; Tue, 20 Aug 2002 19:00:05 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KN05U25699; Tue, 20 Aug 2002 19:00:05 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 19:00:05 -0400 (EDT) Resent-Message-Id: <200208202300.g7KN05U25699@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KN04v25679 for ; Tue, 20 Aug 2002 19:00:04 -0400 (EDT) Received: from localhost.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 TAA13188 for ; Tue, 20 Aug 2002 19:00:03 -0400 Received: from localhost (localhost [127.0.0.1]) by localhost.wakasoft.com (8.12.4/8.12.4) with ESMTP id g7KN0GAq007061; Tue, 20 Aug 2002 16:00:16 -0700 (PDT) Date: Tue, 20 Aug 2002 16:00:15 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: "Lisa Dusseault" From: "Roy T. Fielding" In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BD9@ATL1VEXC006.usdom004.tco.tc> Message-Id: <9731CD4E-B490-11D6-868F-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Subject: Re: IPv6 support in WebDAV and HTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6521 X-Loop: w3c-dist-auth@w3.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 > RFC2616 says: "http_URL = "http:" "//" host [ ":" port ] [ abs_path [ > "?" query ]]" > > I can't find a definition of the host part. It does however say "The > use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC > 1900 [24])." > > So: > - Does the wording in RFC2616 require support for IPv6 for HTTP > servers? Or does it merely skirt the issue? It doesn't say anything about it. > - Does anybody have any idea how HTTP servers and clients handle IPv6 > addresses in practice? Origin servers don't see them in practice. I think we enabled IPv6 literals for Apache httpd's mod_proxy in 2.0, but I haven't verified. I don't know about clients -- check the Mozilla port to IPv6. > I assume RFC2518bis should update its references to RFC2396 to RFC2616, > which results in removing the restriction to IPv4 addresses only. 2616 defines the http URI scheme (poorly). 2396 defines all URI. You will need both references. ....Roy From w3c-dist-auth-request@w3.org Tue Aug 20 19:24:51 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00113 for ; Tue, 20 Aug 2002 19:24:51 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA17599; Tue, 20 Aug 2002 19:24:59 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KNOwN27523; Tue, 20 Aug 2002 19:24:58 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 19:24:58 -0400 (EDT) Resent-Message-Id: <200208202324.g7KNOwN27523@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KNOuv27490 for ; Tue, 20 Aug 2002 19:24:56 -0400 (EDT) Received: from raging.dropbear.id.au (postfix@[203.36.158.121]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA17579 for ; Tue, 20 Aug 2002 19:24:55 -0400 Received: by raging.dropbear.id.au (Postfix, from userid 1000) id 19BA214AC961; Wed, 21 Aug 2002 09:24:48 +1000 (EST) Date: Wed, 21 Aug 2002 09:24:47 +1000 From: Daniel Stone To: Lisa Dusseault Cc: "Roy T. Fielding" , w3c-dist-auth@w3c.org Message-ID: <20020820232447.GD14717@raging.dropbear.id.au> References: <27889B08CAEC7049B68FAD8717BA6017371BD9@ATL1VEXC006.usdom004.tco.tc> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bajzpZikUji1w+G9" Content-Disposition: inline In-Reply-To: <27889B08CAEC7049B68FAD8717BA6017371BD9@ATL1VEXC006.usdom004.tco.tc> User-Agent: Mutt/1.3.28i Subject: Re: IPv6 support in WebDAV and HTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6522 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --bajzpZikUji1w+G9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 20, 2002 at 06:40:05PM -0400, Lisa Dusseault wrote: >=20 > RFC2616 says: "http_URL =3D "http:" "//" host [ ":" port ] [ abs_path [ > "?" query ]]" >=20 > I can't find a definition of the host part. It does however say "The > use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC > 1900 [24])." >=20 > So:=20 > - Does the wording in RFC2616 require support for IPv6 for HTTP > servers? Or does it merely skirt the issue? > - Does anybody have any idea how HTTP servers and clients handle IPv6 > addresses in practice? > > > [...] > > > a > > > set of four decimal digit groups separated by ".". Literal IPv6 > > > addresses are not supported." It only says "literal IPv6 addresses are not supported". In no way does it say, "a name which only has an AAAA/A6 record is invalid". If you *do* want to do literal IPv6 addresses, the accepted form is [host]:port, e.g: [3ffe:8001:c:1001::c0ff:ee]:80 for my home machine. I'm running IPv6 servers and clients with absolutely no issues. HTH, :) d=20 --=20 Daniel Stone http://raging.dropbear.id.= au KDE Developer http://www.kde.org Kopete: Multi-protocol IM client http://kopete.kde.org --bajzpZikUji1w+G9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Ys+/cPClnTztfv0RAjt1AJ9UhjfXYvl+8gamVVQYDrxZcxPnuwCcCX1L n1WbkG0NrhDFLNt5pbRsTqw= =BbFD -----END PGP SIGNATURE----- --bajzpZikUji1w+G9-- From w3c-dist-auth-request@w3.org Tue Aug 20 19:39:42 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00376 for ; Tue, 20 Aug 2002 19:39:42 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA19962; Tue, 20 Aug 2002 19:39:05 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7KNd5h29183; Tue, 20 Aug 2002 19:39:05 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 19:39:05 -0400 (EDT) Resent-Message-Id: <200208202339.g7KNd5h29183@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7KNd4v29148 for ; Tue, 20 Aug 2002 19:39:04 -0400 (EDT) Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA19944 for ; Tue, 20 Aug 2002 19:39:04 -0400 Received: from manyfish.co.uk ([62.253.142.7]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020820233903.DOZA25423.mta01-svc.ntlworld.com@manyfish.co.uk> for ; Wed, 21 Aug 2002 00:39:03 +0100 Received: (from joe@localhost) by manyfish.co.uk (8.11.6/8.11.6) id g7KNd2S05643 for w3c-dist-auth@w3c.org; Wed, 21 Aug 2002 00:39:03 +0100 Date: Wed, 21 Aug 2002 00:39:02 +0100 From: Joe Orton To: w3c-dist-auth@w3c.org Message-ID: <20020821003902.A2423@light.plus.com> Mail-Followup-To: w3c-dist-auth@w3c.org References: <27889B08CAEC7049B68FAD8717BA6017371BD9@ATL1VEXC006.usdom004.tco.tc> <9731CD4E-B490-11D6-868F-000393753936@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9731CD4E-B490-11D6-868F-000393753936@apache.org>; from fielding@apache.org on Tue, Aug 20, 2002 at 04:00:15PM -0700 Subject: Re: IPv6 support in WebDAV and HTTP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6523 X-Loop: w3c-dist-auth@w3.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, Aug 20, 2002 at 04:00:15PM -0700, Roy Fielding wrote: > > - Does anybody have any idea how HTTP servers and clients handle IPv6 > > addresses in practice? > > Origin servers don't see them in practice. Host headers may contain IPv6 addresses though, clients will send these (at least Mozilla will). > I think we enabled IPv6 > literals > for Apache httpd's mod_proxy in 2.0, but I haven't verified. I don't > know about clients -- check the Mozilla port to IPv6. It looks like the URI parser in 2.0 doesn't know about the IPv6 address syntax from RFC2372... a request like this fails with a 400 error: MOVE /dav/a HTTP/1.1 Host: [feed::1]:8080 Destination: http://[feed::1]:8080/dav/b Regards, joe From w3c-dist-auth-request@w3.org Tue Aug 20 21:49:21 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03316 for ; Tue, 20 Aug 2002 21:49:21 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA09543; Tue, 20 Aug 2002 21:49:32 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7L1nUD12859; Tue, 20 Aug 2002 21:49:30 -0400 (EDT) Resent-Date: Tue, 20 Aug 2002 21:49:30 -0400 (EDT) Resent-Message-Id: <200208210149.g7L1nUD12859@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7L1nTv12835 for ; Tue, 20 Aug 2002 21:49:29 -0400 (EDT) Received: from gcsu.edu (vir.gcsu.edu [168.16.214.18]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA09508 for ; Tue, 20 Aug 2002 21:49:28 -0400 Received: by gcsu.edu; id VAA21639; Tue, 20 Aug 2002 21:51:31 -0400 (EDT) Received: from gcsu211076.gcsu.edu(168.16.211.76) by vir.gcsu.edu via csmap (V4.1) id srcAAAWtaOqQ; Tue, 20 Aug 02 21:51:30 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 20 Aug 2002 21:48:47 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: WebDAV and WindowsXP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6524 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: We had been working successfully with a webDAV enabled server (WebSTAR V 5.1.3) and Windows 98 and Windows 2000. Previously, we'd been told that our university would not be deploying WindowsXP but suddenly there was a change of plans and we found ourselves having to work with WindowsXP Dell laptops. All of the things that had worked well before (Web Folders, Network Places, FrontPage 2002, etc.) no longer seem to work in the XP environment. We have a few confounding variables operative at the moment (some vague network problems) that are making it difficult to pin this sudden loss of functionality squarely on XP. Can anyone with more experience working in a trouble free networking environment and with XP and WebDAV confirm or deny this suspicion? Please CC any responses as I'm quite anxious to get closure 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 Wed Aug 21 01:47:30 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08054 for ; Wed, 21 Aug 2002 01:47:30 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA14884; Wed, 21 Aug 2002 01:46:36 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7L5jQq02188; Wed, 21 Aug 2002 01:45:26 -0400 (EDT) Resent-Date: Wed, 21 Aug 2002 01:45:26 -0400 (EDT) Resent-Message-Id: <200208210545.g7L5jQq02188@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7L5jOv02168 for ; Wed, 21 Aug 2002 01:45:24 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA14648 for ; Wed, 21 Aug 2002 01:45:24 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7L5ioha024080; Wed, 21 Aug 2002 01:44:50 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7L5inMw058164; Wed, 21 Aug 2002 01:44:49 -0400 To: "Julian Reschke" Cc: "'Babich, Alan'" , "'Julian Reschke'" , "Lisa Dusseault" , w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Tue, 20 Aug 2002 23:16:25 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_M14_08012002 Release Candidate|August 01, 2002) at 08/21/2002 01:44:48 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: xml:space Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6525 X-Loop: w3c-dist-auth@w3.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'm going to mark issue IS_XMLSPACE_SIGNIFICANT as resolves that simply Whitespace is significant. As 2518bis already states. J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Thu Aug 22 20:19:15 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14411 for ; Thu, 22 Aug 2002 20:19:14 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA18561; Thu, 22 Aug 2002 20:19:03 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7N0IN209124; Thu, 22 Aug 2002 20:18:23 -0400 (EDT) Resent-Date: Thu, 22 Aug 2002 20:18:23 -0400 (EDT) Resent-Message-Id: <200208230018.g7N0IN209124@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7N0IGv09102 for ; Thu, 22 Aug 2002 20:18:16 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA18429 for ; Thu, 22 Aug 2002 20:18:16 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g7N0HeT17808; Thu, 22 Aug 2002 17:17:40 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV" Date: Thu, 22 Aug 2002 17:15:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: Coming to Interoperability Testing Event? Let me know! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6526 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a quick reminder that there will be an Interoperability Testing Event for WebDAV/DeltaV/DASL/ACL implementations to be held September 9-11, 2002, at UC Santa Cruz, in the Jack Baskin Engineering building. The purpose of the event is to gather together implementors of WebDAV/DeltaV/DASL/ACL clients and servers, and allow them to easily test against one anothers implementations in a very rapid manner. Last year's event was attended by 55 people, and was very successful. So far, I have heard that people from the following companies will be attending the event: Microsoft, Adobe, Apple, Xythos, Merant, NetApp, Alias/Wavefront, & Sambar. As well, we anticipate having a significantly enhanced version of Litmus on-hand for automated compliance testing, as well as the Catacomb server, and a DASL-enabled version of Cadaver. If you're planning on attending the event, please let me know soon, so I have accurate numbers for meal and space planning. There is a small $225 charge per organization to attend, primarily to cover the cost of food and parking. - Jim Whitehead ejw@cs.ucsc.edu From w3c-dist-auth-request@w3.org Mon Aug 26 05:31:56 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04605 for ; Mon, 26 Aug 2002 05:31:55 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA18263; Mon, 26 Aug 2002 05:31:19 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7Q9UTQ27225; Mon, 26 Aug 2002 05:30:29 -0400 (EDT) Resent-Date: Mon, 26 Aug 2002 05:30:29 -0400 (EDT) Resent-Message-Id: <200208260930.g7Q9UTQ27225@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7Q9UQv27121 for ; Mon, 26 Aug 2002 05:30:26 -0400 (EDT) Received: from xp500 (adsl-nk-A2416.hitron.net [203.79.163.130]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA17756; Mon, 26 Aug 2002 05:29:22 -0400 Date: Mon, 26 Aug 2002 05:29:22 -0400 Received: from tpts7 by mail.sysnet.net.tw with SMTP id Jt4y4nZYDzMUpEGeJ4Y6; Mon, 26 Aug 2002 17:29:53 +0800 Message-ID: <97mr0tJ7fkk9Rm@party.seed.net.tw> From: time@w3.org To: 012@tux.w3.org MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_tKXxrwwQos8Gbr0GY1Iw7O" X-Mailer: 6kO8TIyLYJzD1QKC X-Priority: 3 X-MSMail-Priority: Normal Subject: =?big5?Q?=A6=AC=C1=CA=A4=E2=BF=F6?= Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6527 X-Loop: w3c-dist-auth@w3.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_tKXxrwwQos8Gbr0GY1Iw7O Content-Type: multipart/alternative; boundary="----=_NextPart_tKXxrwwQos8Gbr0GY1Iw7OAA" ------=_NextPart_tKXxrwwQos8Gbr0GY1Iw7OAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 DQo8SFRNTD48SEVBRD48VElUTEU+sKq7+aaswcqk4r/2PC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1iaWc1Ij48YmFzZQ0K aHJlZj1odHRwOi8vbmV0Y2l0eTMud2ViLmhpbmV0Lm5ldC9Vc2VyRGF0YS9hbGdvMS9hZC93YXRj aDEuaHRtPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjcxNi4yMjAwIiBuYW1lPUdFTkVS QVRPUj48L0hFQUQ+DQo8Qk9EWSB0ZXh0PSMwMDAwMDAgYmdDb2xvcj0jZmZjY2NjIGxlZnRNYXJn aW49MCB0b3BNYXJnaW49MD4NCjxUQUJMRSBjZWxsU3BhY2luZz0xIGNlbGxQYWRkaW5nPTAgd2lk dGg9NjAwIGFsaWduPWNlbnRlciBiZ0NvbG9yPSNmZjAwNjYgDQpib3JkZXI9MD4NCiAgPFRCT0RZ Pg0KICA8VFI+DQogICAgPFREIGFsaWduPW1pZGRsZSBiZ0NvbG9yPSNmZmVjZWM+DQogICAgICA8 VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSIxMDAlIiBib3JkZXI9MD4N CiAgICAgICAgPFRCT0RZPiANCiAgICAgICAgPFRSIHZBbGlnbj10b3A+IA0KICAgICAgICAgIDxU RCBjb2xTcGFuPTMgaGVpZ2h0PTcwPiANCiAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0iNjAwIiBi b3JkZXI9IjAiIGhlaWdodD0iMzAzIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPg0K ICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgIDx0ZD48aW1nIHNyYz0iaW1hZ2Vz L3dhdGNoal8xLmpwZyIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI3NiI+PC90ZD4NCiAgICAgICAgICAg ICAgICA8dGQ+PGltZyBzcmM9ImltYWdlcy93YXRjaGpfMi5qcGciIHdpZHRoPSIxNTAiIGhlaWdo dD0iNzYiPjwvdGQ+DQogICAgICAgICAgICAgICAgPHRkPjxpbWcgc3JjPSJpbWFnZXMvd2F0Y2hq XzMuanBnIiB3aWR0aD0iMTUwIiBoZWlnaHQ9Ijc2Ij48L3RkPg0KICAgICAgICAgICAgICAgIDx0 ZD48aW1nIHNyYz0iaW1hZ2VzL3dhdGNoal80LmpwZyIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI3NiI+ PC90ZD4NCiAgICAgICAgICAgICAgPC90cj4NCiAgICAgICAgICAgICAgPHRyPiANCiAgICAgICAg ICAgICAgICA8dGQ+PGltZyBzcmM9ImltYWdlcy93YXRjaGpfNS5qcGciIHdpZHRoPSIxNTAiIGhl aWdodD0iNzYiPjwvdGQ+DQogICAgICAgICAgICAgICAgPHRkPjxpbWcgc3JjPSJpbWFnZXMvd2F0 Y2hqXzYuanBnIiB3aWR0aD0iMTUwIiBoZWlnaHQ9Ijc2Ij48L3RkPg0KICAgICAgICAgICAgICAg IDx0ZD48aW1nIHNyYz0iaW1hZ2VzL3dhdGNoal83LmpwZyIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI3 NiI+PC90ZD4NCiAgICAgICAgICAgICAgICA8dGQ+PGltZyBzcmM9ImltYWdlcy93YXRjaGpfOC5q cGciIHdpZHRoPSIxNTAiIGhlaWdodD0iNzYiPjwvdGQ+DQogICAgICAgICAgICAgIDwvdHI+DQog ICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAgPHRkPjxpbWcgc3JjPSJpbWFnZXMv d2F0Y2hqXzkuanBnIiB3aWR0aD0iMTUwIiBoZWlnaHQ9Ijc2Ij48L3RkPg0KICAgICAgICAgICAg ICAgIDx0ZD48aW1nIHNyYz0iaW1hZ2VzL3dhdGNoal8xMC5qcGciIHdpZHRoPSIxNTAiIGhlaWdo dD0iNzYiPjwvdGQ+DQogICAgICAgICAgICAgICAgPHRkPjxpbWcgc3JjPSJpbWFnZXMvd2F0Y2hq XzExLmpwZyIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI3NiI+PC90ZD4NCiAgICAgICAgICAgICAgICA8 dGQ+PGltZyBzcmM9ImltYWdlcy93YXRjaGpfMTIuanBnIiB3aWR0aD0iMTUwIiBoZWlnaHQ9Ijc2 Ij48L3RkPg0KICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgICA8dHI+IA0KICAgICAg ICAgICAgICAgIDx0ZD48aW1nIHNyYz0iaW1hZ2VzL3dhdGNoal8xMy5qcGciIHdpZHRoPSIxNTAi IGhlaWdodD0iNzUiPjwvdGQ+DQogICAgICAgICAgICAgICAgPHRkPjxpbWcgc3JjPSJpbWFnZXMv d2F0Y2hqXzE0LmpwZyIgd2lkdGg9IjE1MCIgaGVpZ2h0PSI3NSI+PC90ZD4NCiAgICAgICAgICAg ICAgICA8dGQ+PGltZyBzcmM9ImltYWdlcy93YXRjaGpfMTUuanBnIiB3aWR0aD0iMTUwIiBoZWln aHQ9Ijc1Ij48L3RkPg0KICAgICAgICAgICAgICAgIDx0ZD48aW1nIHNyYz0iaW1hZ2VzL3dhdGNo al8xNi5qcGciIHdpZHRoPSIxNTAiIGhlaWdodD0iNzUiPjwvdGQ+DQogICAgICAgICAgICAgIDwv dHI+DQogICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgDQogICAgICAgICAgPC9URD4N CiAgICAgICAgPC9UUj4NCiAgICAgICAgPFRSPiANCiAgICAgICAgICA8VEQgdkFsaWduPWNlbnRl ciBhbGlnbj1taWRkbGUgY29sU3Bhbj0zPiZuYnNwOyA8L1REPg0KICAgICAgICA8L1RSPg0KICAg ICAgICA8VFI+IA0KICAgICAgICAgIDxURCBiZ0NvbG9yPSNlYTAwNzUgY29sU3Bhbj0zIGhlaWdo dD0yNT4gDQogICAgICAgICAgICA8RElWIGFsaWduPWNlbnRlcj4NCiAgICAgICAgICAgICAgPHA+ Jm5ic3A7PC9wPg0KICAgICAgICAgICAgICA8cD48U1BBTiBjbGFzcz1UQj48Rk9OVCBjbGFzcz1U QiANCiAgICAgICAgICAgIGNvbG9yPSNmZmZmZmY+PEI+PGZvbnQgc2l6ZT0iNCI+p9qtzKxPsU23 fqq6xMG/9sWyqXeudiwoq0S37edFqc6kQK/rpKSlarDTKTwvZm9udD48L0I+PC9GT05UPjwvU1BB Tj48L3A+DQogICAgICAgICAgICAgIDxwPjxmb250IHNpemU9IjQiPjxTUEFOIGNsYXNzPVRCPjxG T05UIGNsYXNzPVRCIA0KICAgICAgICAgICAgY29sb3I9I2ZmZmZmZj48Qj6xTar5pqzByqZVpGq8 dLVQpKek4r/2PC9CPjwvRk9OVD48L1NQQU4+PC9mb250PjwvcD4NCiAgICAgICAgICAgICAgPHA+ PGZvbnQgc2l6ZT0iNCI+PFNQQU4gY2xhc3M9VEI+PEZPTlQgY2xhc3M9VEIgDQogICAgICAgICAg ICBjb2xvcj0jZmZmZmZmPjxCPsF8pFq356RoplWkarx0tVCkp63suMuk4r/2PC9CPjwvRk9OVD48 L1NQQU4+PC9mb250PjwvcD4NCiAgICAgICAgICAgICAgPHA+PGZvbnQgc2l6ZT0iNCI+PFNQQU4g Y2xhc3M9VEI+PEZPTlQgY2xhc3M9VEIgDQogICAgICAgICAgICBjb2xvcj0jZmZmZmZmPjxCPqZw OqbKuUa7QsRSLLdSqbwss9KkT6RoLKjIpsytWCyu9rVeLKVkq9KoyC4uLi61paehpWk8L0I+PC9G T05UPjwvU1BBTj48L2ZvbnQ+PC9wPg0KICAgICAgICAgICAgICA8cD48Zm9udCBzaXplPSI0Ij48 U1BBTiBjbGFzcz1UQj48Rk9OVCBjbGFzcz1UQiANCiAgICAgICAgICAgIGNvbG9yPSNmZmZmZmY+ PEI+t3PCwqSjqessp9qtzLFOpUiye6r3plaxesHKtlI8L0I+PC9GT05UPjwvU1BBTj48L2ZvbnQ+ PC9wPg0KICAgICAgICAgICAgICA8cD48Zm9udCBzaXplPSI0Ij48U1BBTiBjbGFzcz1UQj48Rk9O VCBjbGFzcz1UQiANCiAgICAgICAgICAgIGNvbG9yPSNmZmZmZmY+PEI+xXeq76jTuXGsor3NOjA5 Mzk2NTIwOTIgqkyl/aXNPC9CPjwvRk9OVD48L1NQQU4+PC9mb250PjwvcD4NCiAgICAgICAgICAg IDwvRElWPg0KICAgICAgICAgIDwvVEQ+DQogICAgICAgIDwvVFI+DQogICAgICAgIDxUUiBhbGln bj1taWRkbGU+IA0KICAgICAgICAgIDxURCBjb2xTcGFuPTMgaGVpZ2h0PTEwMD4gDQogICAgICAg ICAgICA8VEFCTEUgY2VsbFNwYWNpbmc9MSBjZWxsUGFkZGluZz0zIHdpZHRoPSIxMDAlIiBiZ0Nv bG9yPSM2NjY2Y2MgDQogICAgICAgICAgICBib3JkZXI9MD4NCiAgICAgICAgICAgICAgPFRCT0RZ PiANCiAgICAgICAgICAgICAgPFRSPiANCiAgICAgICAgICAgICAgICA8VEQgY2xhc3M9VEEgYmdD b2xvcj0jZmZlY2VjPiANCiAgICAgICAgICAgICAgICAgIDxkaXYgYWxpZ249ImNlbnRlciI+IA0K ICAgICAgICAgICAgICAgICAgICA8cD48YSBocmVmPSJodHRwOi8vbmV0Y2l0eTMud2ViLmhpbmV0 Lm5ldC9Vc2VyRGF0YS9hbGdvMS8iPjxpbWcgc3JjPSIuLi9wc2VuZC5naWYiIHdpZHRoPSIxMjAi IGhlaWdodD0iNjUiIGJvcmRlcj0iMCI+PC9hPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgPHA+ PGEgaHJlZj0iaHR0cDovL25ldGNpdHkzLndlYi5oaW5ldC5uZXQvVXNlckRhdGEvYWxnbzEvIj48 Zm9udCBzaXplPSI1Ij6rwrbHvHOnabNdrXClTrVvt36wyDwvZm9udD48L2E+PC9wPg0KICAgICAg ICAgICAgICAgICAgICA8cD6rS6l5oUK56qZioUK9VLnqoUK426tIoUKuxKpHqM48L3A+DQogICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L1REPg0KICAgICAgICAgICAg ICA8L1RSPg0KICAgICAgICAgICAgICA8L1RCT0RZPiANCiAgICAgICAgICAgIDwvVEFCTEU+DQog ICAgICAgICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPjxhIGhyZWY9Imh0dHA6Ly9uZXRjaXR5My53 ZWIuaGluZXQubmV0L1VzZXJEYXRhL2FsZ28xLyI+PGltZyBzcmM9Ii4uL0FGRi5naWYiIHdpZHRo PSI0NzkiIGhlaWdodD0iOTgiIGJvcmRlcj0iMCI+PC9hPjwvZGl2Pg0KICAgICAgICAgIDwvVEQ+ DQogICAgICAgIDwvVFI+DQogICAgICAgIDwvVEJPRFk+IA0KICAgICAgPC9UQUJMRT4NCiAgICA8 L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPg0KPC9CT0RZPjwvSFRNTD4= ------=_NextPart_tKXxrwwQos8Gbr0GY1Iw7OAA-- ------=_NextPart_tKXxrwwQos8Gbr0GY1Iw7O-- From w3c-dist-auth-request@w3.org Mon Aug 26 18:06:20 2002 Received: from tux.w3.org (IDENT:root@tux.w3.org [18.29.0.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23815 for ; Mon, 26 Aug 2002 18:06:20 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA06550; Mon, 26 Aug 2002 18:06:17 -0400 Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7QM6Ec11637; Mon, 26 Aug 2002 18:06:14 -0400 (EDT) Resent-Date: Mon, 26 Aug 2002 18:06:14 -0400 (EDT) Resent-Message-Id: <200208262206.g7QM6Ec11637@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7QM6Dv11613 for ; Mon, 26 Aug 2002 18:06:13 -0400 (EDT) Received: from sunbelt.seagull.net ([199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA06502 for ; Mon, 26 Aug 2002 18:06:12 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id PAA13634 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Mon, 26 Aug 2002 15:06:11 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id PAA13626 sender obsfucated@us.ibm.com; Mon, 26 Aug 2002 15:06:10 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7QM5dha109464; Mon, 26 Aug 2002 18:05:39 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g7QM5aEC101040; Mon, 26 Aug 2002 18:05:36 -0400 To: Cc: "Jim Whitehead" , "Roy T. Fielding" , "Julian Reschke" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Mon, 26 Aug 2002 18:02:53 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Build V60_M14_08012002 Release Candidate|August 01, 2002) at 08/26/2002 18:05:36 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6528 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Okay guys, We've gotten stuck again on this topic. We last left the discussion back near July 1 where I asked us to try to resolve the issue of whether we use the XLink approach to roles or if we use dav:href tags. Julian has advocated XLink... http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0250.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0006.html Geoff has advocated dav:href http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0022.html But no one responded to them and the discussion died. Lisa asks and requests that we demonstrate interoperability at the upcoming iterop. If we don't, the source property will need to be removed so that webdav can continue down the standards track. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0096.html If you feel it's important to retain the source property in the next draft of WebDAV you should speak up now. Who plans to implement dav:source in their offerings? Jason. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Tue Aug 27 09:00:49 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22005 for ; Tue, 27 Aug 2002 09:00:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7RCxnA25763; Tue, 27 Aug 2002 08:59:49 -0400 (EDT) Resent-Date: Tue, 27 Aug 2002 08:59:49 -0400 (EDT) Resent-Message-Id: <200208271259.g7RCxnA25763@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7RCxlv25743 for ; Tue, 27 Aug 2002 08:59:47 -0400 (EDT) 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 IAA29723 for ; Tue, 27 Aug 2002 08:59:46 -0400 Received: (qmail 2305 invoked by uid 0); 27 Aug 2002 12:59:15 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 27 Aug 2002 12:59:15 -0000 From: "Julian Reschke" To: "Jason Crawford" , Cc: "Jim Whitehead" , "Roy T. Fielding" , "Julian Reschke" Date: Tue, 27 Aug 2002 14:59:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6529 X-Loop: w3c-dist-auth@w3.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, let's start at the end: the issue seems to be that none of the servers is actually planning to add DAV:source support. So the answer to Lisa would be: we can't come up with a solution in time for the next draft, so the feature should be dropped (well, or the schedule changed). Funny enough, the question of to XLink or not is now a TAG issue, and I'm very interested to see what the outcome will be... :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Tuesday, August 27, 2002 12:03 AM > To: w3c-dist-auth@w3c.org > Cc: Jim Whitehead; Roy T. Fielding; Julian Reschke > Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED > > > > Okay guys, > We've gotten stuck again on this topic. We last left the discussion > back near July 1 where I asked us to try to resolve the issue of > whether we > use the XLink approach to roles or if we use dav:href tags. > > Julian has advocated XLink... > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0250.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0006.html > > Geoff has advocated dav:href > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0022.html > > But no one responded to them and the discussion died. > > > Lisa asks and requests that we demonstrate interoperability at the > upcoming iterop. If we don't, the source property will need to be > removed so that webdav can continue down the standards track. > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0096.html > > If you feel it's important to retain the source property in the next draft > of > WebDAV you should speak up now. Who plans to implement dav:source > in their offerings? > > Jason. > > > ------------------------------------------ > Phone: 914-784-7569 > From w3c-dist-auth-request@w3.org Thu Aug 29 14:57:12 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06717 for ; Thu, 29 Aug 2002 14:57:12 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7TIuWS04027; Thu, 29 Aug 2002 14:56:32 -0400 (EDT) Resent-Date: Thu, 29 Aug 2002 14:56:32 -0400 (EDT) Resent-Message-Id: <200208291856.g7TIuWS04027@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7TIuVv04007 for ; Thu, 29 Aug 2002 14:56:31 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA05653 for ; Thu, 29 Aug 2002 14:56:30 -0400 Received: from Tycho (dhcp-63-177.cse.ucsc.edu [128.114.63.177]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g7TIuGg14502 for ; Thu, 29 Aug 2002 11:56:17 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 29 Aug 2002 11:54:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: [Moderator Action] WebDAV clients which work over Netscape Proxies? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6530 X-Loop: w3c-dist-auth@w3.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: imagine@nsc.nsc.com [mailto:imagine@nsc.nsc.com]On Behalf Of Jason Sent: Wednesday, August 28, 2002 7:31 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] WebDAV clients which work over Netscape Proxies? Hello Greg, I was wondering if you had any info about how best to make use of WebDAV, from a Windooooz machine, over a Netscape Proxy? Any recommended clients, other than IE and the web folders schema? It seems Netscape proxy's do not support WebDAV. Any info would be greatly appreciated. Thanks. -- Regards, Jason H Carroll ********************************************* * * * \\\|/// * * \\ - - // * * (/ @ @ \) * * ---------oOOo-(_)-oOOo-------- * * * * * * What the large print giveth * * the small print taketh away * * * * -anonymous mortgage banker * * * ********************************************* From w3c-dist-auth-request@w3.org Thu Aug 29 16:20:14 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09761 for ; Thu, 29 Aug 2002 16:20:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g7TKKL413887; Thu, 29 Aug 2002 16:20:21 -0400 (EDT) Resent-Date: Thu, 29 Aug 2002 16:20:21 -0400 (EDT) Resent-Message-Id: <200208292020.g7TKKL413887@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g7TKKKv13865 for ; Thu, 29 Aug 2002 16:20:20 -0400 (EDT) Received: from out002.iad.hostedmail.net (out002.iad.hostedmail.net [209.225.56.24]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA24118 for ; Thu, 29 Aug 2002 16:20:20 -0400 Received: from 10.158.10.14 by out002.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 29 Aug 2002 16:19:10 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.182]) by atl1simr002.tco.tc with Microsoft SMTPSVC(5.0.2195.2966); Thu, 29 Aug 2002 16:19:09 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 29 Aug 2002 16:19:09 -0400 From: "Lisa Dusseault" To: , Date: Thu, 29 Aug 2002 13:19:09 -0700 Message-ID: <004101c24f99$55a32120$b601a8c0@xythoslap> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 29 Aug 2002 20:19:09.0596 (UTC) FILETIME=[55170DC0:01C24F99] Subject: Announcement of WebDAV WG Interim Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6531 X-Loop: w3c-dist-auth@w3.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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C24F5E.A9444920" ------=_NextPart_000_0042_01C24F5E.A9444920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WebDAV WG will be holding an interim WG meeting during the WebDAV Interop event. Dates: September 9-11 2002. Location: UC Santa Cruz, CA, USA (Jack Baskin Engineering building). Times: 9:00 am to 6:00 pm is the general interop time. A meeting room has been reserved for WG discussions, at the specific times below. To register for the event, please send mail to Jim Whitehead, ejw@cs.ucsc.edu. The interop event itself involves a small fee but attendees of just the WG meeting of course will not be charged. Agenda: ------ Sept 9, 3:00 pm to 6:00 pm: Status: ACL standard to RFC - 20 min Status: Search work progress - 20 min RFC2518 bis issues discussion - 1.5 hours Sept 10 (3:00 pm to 6:00 pm) and Sept 11 (9:00 am to 12:00 am): RFC2518 interoperability issues - 2 hours + ACL interoperability issues - 30 min DeltaV interoperability findings, if any - 20 min Search interoperability findings, if any - 20 min ------=_NextPart_000_0042_01C24F5E.A9444920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WebDAV WG will = be holding an interim WG meeting during the WebDAV

Interop = event.

 

Dates: = September 9-11 2002. 

Location: UC = Santa Cruz, CA, USA (Jack Baskin = Engineering building).

Times: = 9:00 am to 6:00 pm is the general = interop time. A meeting room

has been reserved = for WG discussions, at the specific times below.

 

To register for the = event, please send mail to Jim Whitehead,

ejw@cs.ucsc.edu.  The interop event itself involves a small fee but

attendees of just = the WG meeting of course will not be charged.

 

Agenda:

------

 

Sept 9, = 3:00 pm to 6:00 pm:

Status: ACL = standard to RFC - 20  min

Status: Search work = progress - 20 min

RFC2518 bis issues discussion - 1.5 hours

 

Sept 10 = (3:00 pm to 6:00 pm) and Sept 11 = (9:00 am to 12:00 am): =

RFC2518 = interoperability issues - 2 hours +

ACL = interoperability issues - 30 min

DeltaV = interoperability findings, if any - 20 min

Search = interoperability findings, if any - 20 min

 

 

------=_NextPart_000_0042_01C24F5E.A9444920-- --------------InterScan_NT_MIME_Boundary--