From w3c-dist-auth-request@w3.org Wed Nov 1 14:16:43 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01177 for ; Wed, 1 Nov 2000 14:16:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01715; Wed, 1 Nov 2000 13:56:20 -0500 (EST) Resent-Date: Wed, 1 Nov 2000 13:56:20 -0500 (EST) Resent-Message-Id: <200011011856.NAA01715@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA01658 for ; Wed, 1 Nov 2000 13:56:08 -0500 (EST) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA12424 for ; Wed, 1 Nov 2000 13:56:07 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA11910 for ; Wed, 1 Nov 2000 13:27:50 -0600 Received: from d04nms03.raleigh.ibm.com (d04nms03nms04.raleigh.ibm.com [9.67.228.68]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id NAA67682 for ; Wed, 1 Nov 2000 13:56:02 -0500 To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org Cc: "Scott J McAllister/Raleigh/IBM" , "Hayden Lindsey/Raleigh/IBM" , "Steve Gerdt/San Jose/IBM" , "Edward Lynch/Somers/IBM" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jim Amsden/Raleigh/IBM" Date: Wed, 1 Nov 2000 14:00:46 -0500 X-MIMETrack: Serialize by Router on D04NMS03/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 11/01/2000 01:56:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: DAV4J Source Released on developerWorks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4425 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: IBM is pleased to announce the DAV4J source is now available on developerWorks under the IBM Public License. Full details can be found at the new DAV4J home site at http://oss.software.ibm.com/developerworks/opensource/dav4j. DAV4J will eventually be moved off the alphaWorks site, so update you links to the new developerWorks site. Although DAV4J is hosted under the open source zone on developerWorks, IBM is not creating an Open Source project for DAV4J at this time. We are only making the source available to help support the WebDAV community through: - an offering to promote the development of the WebDAV grounded in the reality of an implementation - a platform for easily exploring the WebDAV protocol and implementation options as it evolves - feedback to the WebDAV working groups based on real implementation experience - a client API that facilitates WebDAV client application development - a server architecture supporting multiple repository managers - an implementation based on the Java and servlet standards supporting WebDAV methods in many current Web servers IBM is also participating in the Apache/mod_dav Open Source effort, and includes mod_dav in the IBM HTTP server (which is Apache). See www.webdav.org for details. I (Jim Amsden) will be monitoring the DAV4J mailing list, and will consider updates, bug fixes, new features, etc., time permitting. The DAV4J client API provides Java client applications with a simple, rich interface for accessing resources managed by a WebDAV server. Using this API, client applications are relieved from managing the details of the low level HTTP communication protocol, constructing and parsing XML request and response entity bodies, and the complexities of the WebDAV semantics. DAV4J also provides a servlet that with WebSphere AppServer extends the Apache Web server with the WebDAV Class 2 protocol. DAV4J provides: 1. Protocol independent (not just WebDAV) communication between client and server applications including support for http:, rmi:, and local access. Support for iiop: may be provided in a future release. Local access is used if the host name in the URL is the local host and no port is specified.\ 2. A high-level, object-oriented interface capturing the WebDAV Class 2 semantics that can interface with any WebDAV Class 2 compliant server. 3. A Java servlet that along with WebSphere AppServer enables DAV Class 2 methods in the Apache Web server. The Apache Web server can be configured so that some URLs can be handled either directly by the Apache server without WebDAV methods while other URLs are handled by the DAV4J servlet with WebDAV methods. This allows a single Apache server to be both a production and authoring server on different partitions of the URL namespace. 4. The ability to access multiple back end repository managers using a single, common, standard, simple protocol: WebDAV. The DAV4J architecture encapsulates low-level repository services required to implement the WebDAV semantics into a number of simple Java interfaces. All that is required to provide WebDAV access to a repository manager is to implement these interfaces on the repository manager. DAV4J includes a repository manager based on the local file system as a reference implementation and example of how to integrate a repository manager. 5. Platform independent, 100% pure Java portability. DAV4J consists of the DAV4J client API, the DAV4J servlet, and the file system repository manager. By changing a few simple properties, Web servers supporting servlets can be configured to support WebDAV methods. The distribution includes configuration information for the Apache Web server and IBM WebSphere AppServer. WebDAV is described in the IETF draft specification RFC2518 From w3c-dist-auth-request@w3.org Wed Nov 1 19:13:48 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11049 for ; Wed, 1 Nov 2000 19:13:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA18238; Wed, 1 Nov 2000 19:00:34 -0500 (EST) Resent-Date: Wed, 1 Nov 2000 19:00:34 -0500 (EST) Resent-Message-Id: <200011020000.TAA18238@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA18217 for ; Wed, 1 Nov 2000 19:00:30 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA09819 for ; Wed, 1 Nov 2000 19:00:31 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.1a/8.9.1) with SMTP id QAA22262 for ; Wed, 1 Nov 2000 16:00:29 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 1 Nov 2000 16:00:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Agenda for San Diego IETF (prelim.) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4426 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa Dusseault reminded me that there is a need to discuss issue concerning improved HTTP error reporting, and Jim Amsden pointed out that there are some aspects of the DeltaV protocol which could be of general use to WebDAV applications. As a result, I've added two new items to the agenda, to cover these issues. Note that Lisa Dusseault (Xythos) will be chairing the meeting in San Diego. If all goes well, I'll have my hands full in Santa Cruz with a new baby... If you have other items for the agenda, please let Lisa or I know. Thank you, Lisa, for chairing this meeting! Preliminary Agenda WebDAV WG meeting Wednesday, December 13, 2000 (3:30-5:30PM) 50min - Open issues and review of the Access Control specification. (Sedlar/Clemm) 30min - Improved HTTP error reporting (Dusseault) 40min - General-purpose WebDAV facilities in the DeltaV protocol (Amsden) The DeltaV working group is also meeting at the San Diego IETF. They are currently scheduled for Thursday, December 14, from 1-3PM. - Jim From w3c-dist-auth-request@w3.org Fri Nov 10 13:50:10 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19601 for ; Fri, 10 Nov 2000 13:50:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10241; Fri, 10 Nov 2000 13:38:30 -0500 (EST) Resent-Date: Fri, 10 Nov 2000 13:38:30 -0500 (EST) Resent-Message-Id: <200011101838.NAA10241@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA10220 for ; Fri, 10 Nov 2000 13:38:27 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA07237 for ; Fri, 10 Nov 2000 13:38:23 -0500 Received: from canuck ([198.144.203.247]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id KAA14160 for ; Fri, 10 Nov 2000 10:38:14 -0800 (PST) From: "Lisa Dusseault" To: Date: Fri, 10 Nov 2000 10:40:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4427 X-Loop: w3c-dist-auth@w3.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 Past discussions have shown that servers frequently have trouble implementing PROPFIND 'allprop'. Jim asked me to summarize the past discussion & list the open issues so that we can get this fixed, if it can be fixed, in revisions to 2518. There are already cases where not all properties will be returned: RFC2518: "In the case of allprop and propname, if a principal does not have the right to know whether a particular property exists then the property should be silently excluded from the response." John Stracke's proposal for reducing/specifying the scope of 'allprop', and discussion of the motivation: - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html It has been a point of discussion for Advanced Collections: - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html "Clients need to know whether the property is computed on the fly before requesting it. There is no way to find out. The impact of computing on the fly is especially significant when a client requests allprop. There may be other properties that are computed on the fly as well. DAV:getetag is computed, and some versioning history properties may also be computed." Also in Versioning: - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html "There has also been a massive growth in the number of available DAV properties. PROPFIND allprop operations may lead to very large responses even with Depth: 1, which would slow down performance for users due to network speeds. It might be worthwhile to add this facet to the open issue ALLPROP_AND_COMPUTED." Also in ACLs, Babich argues that clients who request 'allprop' don't really want to see the ACL property, thus they ought to specifically ask for it. - http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html Several server implementors have voiced the opinion that 'allprop' should be "put out of its misery" (GMC) or at least weakened. Often this is because of standard or custom properties that must be calculated by the server (e.g. 'lockdiscovery'), and the calculation can become extraordinarily expensive with an 'allprop' of depth: infinity. The only server-side argument for keeping 'allprop' is that server-to-server COPY requires it; but if anybody has implemented this yet and can't use 'propname' instead, please speak up. Summary: There thus seems to be a consensus among server implementors and those designing new features for DAV. What's missing in order to resolve this issue for fixing RFC2518 is input from clients. 1. Is anybody aware of clients that rely on particular properties being returned in 'allprop'? If the properties relied upon include any more than the set DAV:{creationdate, displayname, getcontentlanguage, getcontentlength, getcontenttype, getetag, getlastmodified} (the properties required for DAV level 1 support) I would be very surprised. Thus, servers may be able to restrict the required property set to this set. 2. Is anybody aware of clients that rely on 'allprop', rather than 'propname', for property discovery? This would be a more serious issue if major client implementations actually rely on doing property discovery using 'allprop', and attempt this against various implementations of WebDAV servers. These seem to be our options for modifying RFC2518 (remember, it has to be a simple mod): - deprecate 'allprop' and tell clients not to use it, but to use 'propname' instead - define 'allprop' to be the set of properties required for DAV level 1 support (although servers could freely return more properties if desired) - explicitly allow servers to return an error code (507?) for properties that were too expensive to calculate for a 'allprop' request, but still allowing the client to do property discovery through 'allprop' Please voice your preferences among these options, objections, or other ideas. thanks, Lisa Xythos From w3c-dist-auth-request@w3.org Mon Nov 13 07:22:41 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28093 for ; Mon, 13 Nov 2000 07:22:41 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA02837; Mon, 13 Nov 2000 07:08:24 -0500 (EST) Resent-Date: Mon, 13 Nov 2000 07:08:24 -0500 (EST) Resent-Message-Id: <200011131208.HAA02837@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA02814 for ; Mon, 13 Nov 2000 07:08:16 -0500 (EST) 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 HAA30241 for ; Mon, 13 Nov 2000 07:08:13 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id EAA08470; Mon, 13 Nov 2000 04:10:56 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id EAA17555; Mon, 13 Nov 2000 04:06:59 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id NAA04896; Mon, 13 Nov 2000 13:02:38 +0100 (MET) Message-ID: <3A0FD961.FFE2828E@adobe.com> Date: Mon, 13 Nov 2000 13:06:57 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Lisa Dusseault , WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4428 X-Loop: w3c-dist-auth@w3.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 all, I have major concerns regarding the change of the response on a PROPFIND 'allprop' request in the way you described it. Such a change would be *v e r y harmful* for the GoLive 5 WebDAV client. When we send a PROPFIND 'allprop' request we expect all properties which are defined on the resource, especially the Lockproperties and all custom properties defined by GoLive 5 (which we have PROPPATCHED before). We are probably able to replace PROPFIND 'allprop' requests by PROPFIND 'prop' requests in future GoLive releases (which would be indeed much more efficient) but the suggested change in the protocol would be a *disaster* for GoLive 5 which is already in the box. Best, Hartmut Lisa Dusseault wrote: > Past discussions have shown that servers frequently have trouble > implementing PROPFIND 'allprop'. Jim asked me to summarize the past > discussion & list the open issues so that we can get this fixed, if it can > be fixed, in revisions to 2518. > > There are already cases where not all properties will be returned: > RFC2518: "In the case of allprop and propname, if a principal does not have > the > right to know whether a particular property exists then the property > should be silently excluded from the response." > > John Stracke's proposal for reducing/specifying the scope of 'allprop', and > discussion of the motivation: > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > It has been a point of discussion for Advanced Collections: > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > "Clients need to know whether the property is computed on the fly before > requesting it. There is no way to find out. The impact of computing on the > fly is especially significant when a client requests allprop. There may be > other properties that are computed on the fly as well. DAV:getetag is > computed, and some versioning history properties may also be computed." > > Also in Versioning: > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > "There has also been a massive growth in the number of available DAV > properties. PROPFIND allprop operations may lead to very large > responses even with Depth: 1, which would slow down performance > for users due to network speeds. It might be worthwhile to add this > facet to the open issue ALLPROP_AND_COMPUTED." > > Also in ACLs, Babich argues that clients who request 'allprop' don't really > want to see the ACL property, thus they ought to specifically ask for it. > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > Several server implementors have voiced the opinion that 'allprop' should be > "put out of its misery" (GMC) or at least weakened. Often this is because > of standard or custom properties that must be calculated by the server (e.g. > 'lockdiscovery'), and the calculation can become extraordinarily expensive > with an 'allprop' of depth: infinity. > > The only server-side argument for keeping 'allprop' is that server-to-server > COPY requires it; but if anybody has implemented this yet and can't use > 'propname' instead, please speak up. > > Summary: > There thus seems to be a consensus among server implementors and those > designing new features for DAV. What's missing in order to resolve this > issue for fixing RFC2518 is input from clients. > > 1. Is anybody aware of clients that rely on particular properties being > returned in 'allprop'? If the properties relied upon include any more than > the set DAV:{creationdate, displayname, getcontentlanguage, > getcontentlength, getcontenttype, getetag, getlastmodified} (the properties > required for DAV level 1 support) I would be very surprised. Thus, servers > may be able to restrict the required property set to this set. > > 2. Is anybody aware of clients that rely on 'allprop', rather than > 'propname', for property discovery? This would be a more serious issue if > major client implementations actually rely on doing property discovery using > 'allprop', and attempt this against various implementations of WebDAV > servers. > > These seem to be our options for modifying RFC2518 (remember, it has to be a > simple mod): > - deprecate 'allprop' and tell clients not to use it, but to use 'propname' > instead > - define 'allprop' to be the set of properties required for DAV level 1 > support (although servers could freely return more properties if desired) > - explicitly allow servers to return an error code (507?) for properties > that were too expensive to calculate for a 'allprop' request, but still > allowing the client to do property discovery through 'allprop' > > Please voice your preferences among these options, objections, or other > ideas. > > thanks, > Lisa > Xythos From w3c-dist-auth-request@w3.org Mon Nov 13 10:41:18 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28723 for ; Mon, 13 Nov 2000 10:41:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA09366; Mon, 13 Nov 2000 10:26:13 -0500 (EST) Resent-Date: Mon, 13 Nov 2000 10:26:13 -0500 (EST) Resent-Message-Id: <200011131526.KAA09366@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA09346 for ; Mon, 13 Nov 2000 10:26:09 -0500 (EST) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA20932 for ; Mon, 13 Nov 2000 10:25:25 -0500 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id PAA15510 for ; Mon, 13 Nov 2000 15:11:26 GMT Received: from d06mta07.portsmouth.uk.ibm.com (d06mta08_cs0 [9.180.35.21]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id PAA135338 for ; Mon, 13 Nov 2000 15:24:51 GMT Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256996.0054AB06 ; Mon, 13 Nov 2000 15:24:48 +0000 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <80256996.00543911.00@d06mta07.portsmouth.uk.ibm.com> Date: Mon, 13 Nov 2000 15:17:40 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4429 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: ... These seem to be our options for modifying RFC2518 (remember, it has to be a simple mod): - deprecate 'allprop' and tell clients not to use it, but to use 'propname' instead This won't fix the problem, servers still have to deal with clients that fail to follow the deprecation warning. There would be no way to deprecate the call anyway (other than on paper). - define 'allprop' to be the set of properties required for DAV level 1 support (although servers could freely return more properties if desired) This is a breaking change to the spec. I think it is unfair on clients to change the spec. to this extent and at this stage. To a 'legacy' client, the request would appear to have succeeded but only returned partial results, and there would be no indication that this had occurred. The would need to be some means for a client to determine of a server is written to this new definition, which means it is a 'convenient' deprecation. I would support this if the server returned the subset of properties with a new 200-series response code to indicate that the results were incomplete. One could hope that some clients could continue to work in this environment without modification. - explicitly allow servers to return an error code (507?) for properties that were too expensive to calculate for a 'allprop' request, but still allowing the client to do property discovery through 'allprop' IMHO This would be a cleaner solution since clients are presumably already dealing with server errors. Clients would still learn the existance of properties and their names, and smart clients could return to get their values. I suggest that the same error code be available for use with collections that refuse to go deep. It is astounding that a PROPFIND with no depth header and no body is to be interpreted as all prop depth infinity -- the server needs some mechanism to say 'be reasonable client'. From w3c-dist-auth-request@w3.org Mon Nov 13 11:01:59 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06127 for ; Mon, 13 Nov 2000 11:01:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA10712; Mon, 13 Nov 2000 10:48:35 -0500 (EST) Resent-Date: Mon, 13 Nov 2000 10:48:35 -0500 (EST) Resent-Message-Id: <200011131548.KAA10712@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA10692 for ; Mon, 13 Nov 2000 10:48:32 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA23399 for ; Mon, 13 Nov 2000 10:48:32 -0500 Received: from canuck ([198.144.203.247]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id HAA20499; Mon, 13 Nov 2000 07:48:10 -0800 (PST) From: "Lisa Dusseault" To: "Hartmut Warncke" , "WebDAV WG" Date: Mon, 13 Nov 2000 07:49:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A0FD961.FFE2828E@adobe.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4430 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is very good feedback. To clarify, does the GoLive 5 WebDAV client rely on using PROPFIND 'allprop' requests to get all custom properties on **any** webDAV server? or against a specific webDAV server? Have you tested this against various servers? Does it work with all of them? I'd point out that even if the RFC weakens the requirements for supporting 'allprop', existing (shipped) implementations are not going to change, and when new versions come out, they may still support verbose 'allprop' (there will be nothing in the RFC to prevent verbose 'allprop' responses). Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke > Sent: Monday, November 13, 2000 4:07 AM > To: Lisa Dusseault; WebDAV WG > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > Hi all, > > I have major concerns regarding the change of the response on a PROPFIND > 'allprop' request in the way you described it. > > Such a change would be *v e r y harmful* for the GoLive 5 > WebDAV client. > When we send a PROPFIND 'allprop' request we expect all > properties which are > defined on the resource, especially the Lockproperties and all custom > properties defined by GoLive 5 (which we have PROPPATCHED before). > > We are probably able to replace PROPFIND 'allprop' requests by > PROPFIND 'prop' > requests in future GoLive releases (which would be indeed much > more efficient) > but the suggested change in the protocol would be a *disaster* > for GoLive 5 > which is already in the box. > > Best, Hartmut > > > Lisa Dusseault wrote: > > > Past discussions have shown that servers frequently have trouble > > implementing PROPFIND 'allprop'. Jim asked me to summarize the past > > discussion & list the open issues so that we can get this > fixed, if it can > > be fixed, in revisions to 2518. > > > > There are already cases where not all properties will be returned: > > RFC2518: "In the case of allprop and propname, if a principal > does not have > > the > > right to know whether a particular property exists then the property > > should be silently excluded from the response." > > > > John Stracke's proposal for reducing/specifying the scope of > 'allprop', and > > discussion of the motivation: > > - > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > - > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > It has been a point of discussion for Advanced Collections: > > - > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > "Clients need to know whether the property is computed on the fly before > > requesting it. There is no way to find out. The impact of > computing on the > > fly is especially significant when a client requests allprop. > There may be > > other properties that are computed on the fly as well. DAV:getetag is > > computed, and some versioning history properties may also be computed." > > > > Also in Versioning: > > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > "There has also been a massive growth in the number of available DAV > properties. PROPFIND allprop operations may lead to very large > responses even with Depth: 1, which would slow down performance > for users due to network speeds. It might be worthwhile to add this > facet to the open issue ALLPROP_AND_COMPUTED." > > Also in ACLs, Babich argues that clients who request 'allprop' don't really > want to see the ACL property, thus they ought to specifically ask for it. > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > Several server implementors have voiced the opinion that 'allprop' should be > "put out of its misery" (GMC) or at least weakened. Often this is because > of standard or custom properties that must be calculated by the server (e.g. > 'lockdiscovery'), and the calculation can become extraordinarily expensive > with an 'allprop' of depth: infinity. > > The only server-side argument for keeping 'allprop' is that server-to-server > COPY requires it; but if anybody has implemented this yet and can't use > 'propname' instead, please speak up. > > Summary: > There thus seems to be a consensus among server implementors and those > designing new features for DAV. What's missing in order to resolve this > issue for fixing RFC2518 is input from clients. > > 1. Is anybody aware of clients that rely on particular properties being > returned in 'allprop'? If the properties relied upon include any more than > the set DAV:{creationdate, displayname, getcontentlanguage, > getcontentlength, getcontenttype, getetag, getlastmodified} (the properties > required for DAV level 1 support) I would be very surprised. Thus, servers > may be able to restrict the required property set to this set. > > 2. Is anybody aware of clients that rely on 'allprop', rather than > 'propname', for property discovery? This would be a more serious issue if > major client implementations actually rely on doing property discovery using > 'allprop', and attempt this against various implementations of WebDAV > servers. > > These seem to be our options for modifying RFC2518 (remember, it has to be a > simple mod): > - deprecate 'allprop' and tell clients not to use it, but to use 'propname' > instead > - define 'allprop' to be the set of properties required for DAV level 1 > support (although servers could freely return more properties if desired) > - explicitly allow servers to return an error code (507?) for properties > that were too expensive to calculate for a 'allprop' request, but still > allowing the client to do property discovery through 'allprop' > > Please voice your preferences among these options, objections, or other > ideas. > > thanks, > Lisa > Xythos From w3c-dist-auth-request@w3.org Mon Nov 13 11:17:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11658 for ; Mon, 13 Nov 2000 11:17:28 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA11928; Mon, 13 Nov 2000 11:07:51 -0500 (EST) Resent-Date: Mon, 13 Nov 2000 11:07:51 -0500 (EST) Resent-Message-Id: <200011131607.LAA11928@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA11908 for ; Mon, 13 Nov 2000 11:07:47 -0500 (EST) 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 LAA25760 for ; Mon, 13 Nov 2000 11:07:48 -0500 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id IAA28711; Mon, 13 Nov 2000 08:10:34 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id IAA26757; Mon, 13 Nov 2000 08:05:52 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id RAA17348; Mon, 13 Nov 2000 17:02:22 +0100 (MET) Message-ID: <3A101191.18FD3B84@adobe.com> Date: Mon, 13 Nov 2000 17:06:41 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4431 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > To clarify, does the GoLive 5 WebDAV client rely on using PROPFIND 'allprop' > requests to get all custom properties on **any** webDAV server? or against > a specific webDAV server? On **any** WebDAV server. > Have you tested this against various servers? > Does it work with all of them? Yes, it's working against IIS and mod_dav for example. Best, Hartmut > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke > > Sent: Monday, November 13, 2000 4:07 AM > > To: Lisa Dusseault; WebDAV WG > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > Hi all, > > > > I have major concerns regarding the change of the response on a PROPFIND > > 'allprop' request in the way you described it. > > > > Such a change would be *v e r y harmful* for the GoLive 5 > > WebDAV client. > > When we send a PROPFIND 'allprop' request we expect all > > properties which are > > defined on the resource, especially the Lockproperties and all custom > > properties defined by GoLive 5 (which we have PROPPATCHED before). > > > > We are probably able to replace PROPFIND 'allprop' requests by > > PROPFIND 'prop' > > requests in future GoLive releases (which would be indeed much > > more efficient) > > but the suggested change in the protocol would be a *disaster* > > for GoLive 5 > > which is already in the box. > > > > Best, Hartmut > > > > > > Lisa Dusseault wrote: > > > > > Past discussions have shown that servers frequently have trouble > > > implementing PROPFIND 'allprop'. Jim asked me to summarize the past > > > discussion & list the open issues so that we can get this > > fixed, if it can > > > be fixed, in revisions to 2518. > > > > > > There are already cases where not all properties will be returned: > > > RFC2518: "In the case of allprop and propname, if a principal > > does not have > > > the > > > right to know whether a particular property exists then the property > > > should be silently excluded from the response." > > > > > > John Stracke's proposal for reducing/specifying the scope of > > 'allprop', and > > > discussion of the motivation: > > > - > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > > - > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > > > It has been a point of discussion for Advanced Collections: > > > - > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > > "Clients need to know whether the property is computed on the fly before > > > requesting it. There is no way to find out. The impact of > > computing on the > > > fly is especially significant when a client requests allprop. > > There may be > > > other properties that are computed on the fly as well. DAV:getetag is > > > computed, and some versioning history properties may also be computed." > > > > > > Also in Versioning: > > > - > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > > "There has also been a massive growth in the number of available DAV > > properties. PROPFIND allprop operations may lead to very large > > responses even with Depth: 1, which would slow down performance > > for users due to network speeds. It might be worthwhile to add this > > facet to the open issue ALLPROP_AND_COMPUTED." > > > > Also in ACLs, Babich argues that clients who request 'allprop' don't > really > > want to see the ACL property, thus they ought to specifically ask for it. > > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > > > Several server implementors have voiced the opinion that 'allprop' should > be > > "put out of its misery" (GMC) or at least weakened. Often this is because > > of standard or custom properties that must be calculated by the server > (e.g. > > 'lockdiscovery'), and the calculation can become extraordinarily expensive > > with an 'allprop' of depth: infinity. > > > > The only server-side argument for keeping 'allprop' is that > server-to-server > > COPY requires it; but if anybody has implemented this yet and can't use > > 'propname' instead, please speak up. > > > > Summary: > > There thus seems to be a consensus among server implementors and those > > designing new features for DAV. What's missing in order to resolve this > > issue for fixing RFC2518 is input from clients. > > > > 1. Is anybody aware of clients that rely on particular properties being > > returned in 'allprop'? If the properties relied upon include any more > than > > the set DAV:{creationdate, displayname, getcontentlanguage, > > getcontentlength, getcontenttype, getetag, getlastmodified} (the > properties > > required for DAV level 1 support) I would be very surprised. Thus, > servers > > may be able to restrict the required property set to this set. > > > > 2. Is anybody aware of clients that rely on 'allprop', rather than > > 'propname', for property discovery? This would be a more serious issue if > > major client implementations actually rely on doing property discovery > using > > 'allprop', and attempt this against various implementations of WebDAV > > servers. > > > > These seem to be our options for modifying RFC2518 (remember, it has to be > a > > simple mod): > > - deprecate 'allprop' and tell clients not to use it, but to use > 'propname' > > instead > > - define 'allprop' to be the set of properties required for DAV level 1 > > support (although servers could freely return more properties if desired) > > - explicitly allow servers to return an error code (507?) for properties > > that were too expensive to calculate for a 'allprop' request, but still > > allowing the client to do property discovery through 'allprop' > > > > Please voice your preferences among these options, objections, or other > > ideas. > > > > thanks, > > Lisa > > Xythos From w3c-dist-auth-request@w3.org Mon Nov 13 13:02:19 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19793 for ; Mon, 13 Nov 2000 13:02:17 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA17436; Mon, 13 Nov 2000 12:47:37 -0500 (EST) Resent-Date: Mon, 13 Nov 2000 12:47:37 -0500 (EST) Resent-Message-Id: <200011131747.MAA17436@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA17412 for ; Mon, 13 Nov 2000 12:47:32 -0500 (EST) Received: from hermes.eurgw.xerox.com (hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA05020 for ; Mon, 13 Nov 2000 12:43:00 -0500 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id RAA20672 for ; Mon, 13 Nov 2000 17:42:25 GMT Received: from eurgbrmg01.eur.xerox.com (eurgbrmg01.eur.xerox.com [13.202.65.253]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id QAA29831 for ; Mon, 13 Nov 2000 16:45:30 GMT Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by eurgbrmg01.eur.xerox.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 13 Nov 2000 16:45:28 +0000 Received: by EURGBRBH01 with Internet Mail Service (5.5.2651.58) id <4WNGS3LA>; Mon, 13 Nov 2000 16:45:28 -0000 Message-ID: From: "Humphreys, Richard" To: w3c-dist-auth@w3.org Date: Mon, 13 Nov 2000 16:45:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C04D91.20B58EA0" Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4432 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C04D91.20B58EA0 Content-Type: text/plain; charset="iso-8859-1" We spent a great deal of time debating this issue and have come to the following conclusion: 'Allprop' is not the problem - 'depth: infinity' is the problem. Allprop is a perfectly reasonable, even necessary, request. Any client will have a need to know about the complete property namespace for a particular resource. Why then should any sensibly written client need to issue a propfind request with depth infinity? Even if the server has the capacity to build such a horrendous response, the response would probably crash the client when it was received. Two possible solutions arose from our discussions, about which we would welcome constructive criticism: 1- propfind should only be required to accept 'depth:0' and 'depth:1'. Clients who really need more information can then issue requests as needed to go further into the hierarchy. The client will then receive a '501 Not implemented' if it attempts something that nasty. 2- if we have to keep 'depth: infinity', it should not be the default. These suggestions seem reasonable (even ideal!) to us here, but we must concede that we may be biased by the needs of our own particular project. Regards Richard Humphreys Xerox Europe ------_=_NextPart_000_01C04D91.20B58EA0 Content-Type: image/jpeg; name="Notebook.jpg" Content-Disposition: attachment; filename="Notebook.jpg" Content-ID: <552452716@13112000-2b64> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QSyUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA SAAAAAADBgJS//f/9wMPAlsDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////////////// //8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC QAAAAAA4QklNBAkAAAAAAqIAAAABAAAAgAAAAAIAAAGAAAADAAAAAoYAGAAB/9j/4AAQSkZJRgAB AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAIAgAMBIgACEQEDEQH/3QAEAAj/xAE/ AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APROif0Kv6X81T9L j+ar/m/5K0F8rJJIfqlJfKySKn6pSXyskkp+qUl8rJJKfqlJfKySSn6pSXyskkp+qUl8rJJKfqlJ fKySSn//2ThCSU0EBgAAAAAABwABAAAAAQEA//4AJ0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90 b3Nob3CoIDQuMAD/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgNCQ0VDAwVGhQQFBogGxoaGyAiFxcX FxciEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0NDREOERsRERsUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAYBaAD ASIAAhEBAxEB/90ABABa/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwCv0T+n4/8AxrP+qavW15J0U/r+P/xrP+qavWg8eKElsWSHZfXWYe4A+ZUMjIFTJBE/ Fc1kXbg63mJP+amk0uesGqdc19Sup2ZrLmWGQxwLR4B35v8A0V0qKlJJJIqUkkkkpSSSSSlJJJJK UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ JJKUkkkkpSSSSSn/0J9G6oKn04zKKXOdYA6x7d1kOP8Ag/3Hs/MXY/sOl/0hYfCT/wCQavnZJArQ /S1HTXVN21+weYa7/vqzcroeQ+Q3XcYOn/mbF89pIaJfpboXRK+k1uDQPUsILyONPotZ/JatRfKq SSX6qSXyqkip+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqp JfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl 8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXy qkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKq SSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp +qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6 qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn/2Q== ------_=_NextPart_000_01C04D91.20B58EA0-- From w3c-dist-auth-request@w3.org Tue Nov 14 07:02:43 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16050 for ; Tue, 14 Nov 2000 07:02:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA27796; Tue, 14 Nov 2000 06:53:10 -0500 (EST) Resent-Date: Tue, 14 Nov 2000 06:53:10 -0500 (EST) Resent-Message-Id: <200011141153.GAA27796@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id GAA27776 for ; Tue, 14 Nov 2000 06:53:07 -0500 (EST) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id GAA26750 for ; Tue, 14 Nov 2000 06:53:06 -0500 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id LAA103840 for ; Tue, 14 Nov 2000 11:39:06 GMT Received: from d06mta07.portsmouth.uk.ibm.com (d06mta08_cs0 [9.180.35.21]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id LAA92186 for ; Tue, 14 Nov 2000 11:52:32 GMT Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256997.00413AF3 ; Tue, 14 Nov 2000 11:52:29 +0000 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <80256997.0040A1DC.00@d06mta07.portsmouth.uk.ibm.com> Date: Tue, 14 Nov 2000 11:45:31 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4433 X-Loop: w3c-dist-auth@w3.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 spent a great deal of time debating this issue and have come to the following conclusion: 'Allprop' is not the problem - 'depth: infinity' is the problem. I agree that depth infinity is not a good thing. Allprop is a perfectly reasonable, even necessary, request. Any client will have a need to know about the complete property namespace for a particular resource. Why then should any sensibly written client need to issue a propfind request with depth infinity? Even if the server has the capacity to build such a horrendous response, the response would probably crash the client when it was received. I dispute that allprop is necessary. It is a convenient and even reasonable short-hand for using propname and retrieving named properties. The only excuse for a client to issue depth infinity requests is to off-load the traversal work onto the server. This is useful if the comms are an issue, and also if the client is naive (their own depth infinity traversal would have to retain state, watch out for Loop Detected cases, etc.). However, since there is inherently no limit to the number of properties that can be set on a resource, the server has the problem of dealing with potentially large responses (even without depth infinity) provoked by clients that only sent (numerous) small requests. Servers could refuse PROPPATCHes once the resource is 'full' thereby limiting the size of responses. The definition of 'full' would be a function of the number of properties, the size of their values, and, for collections, the 'fullness' of their members. More likely, servers need some equivalent to 'that request is too expensive for me to compute--ask me an easier one' status! Two possible solutions arose from our discussions, about which we would welcome constructive criticism: 1- propfind should only be required to accept 'depth:0' and 'depth:1'. Clients who really need more information can then issue requests as needed to go further into the hierarchy. The client will then receive a '501 Not implemented' if it attempts something that nasty. Refusing to implement depth infinity would be fine. Answering a 501 may be misleading since it would imply that the PROPFIND method is not implemented. It would require some other status condition. 2- if we have to keep 'depth: infinity', it should not be the default. These suggestions seem reasonable (even ideal!) to us here, but we must concede that we may be biased by the needs of our own particular project. I agree it should not be the default. I think an absent depth header should default to depth zero, and an absent method body should default to propnames. Tim From w3c-dist-auth-request@w3.org Tue Nov 14 10:36:27 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24454 for ; Tue, 14 Nov 2000 10:36:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA04247; Tue, 14 Nov 2000 10:21:41 -0500 (EST) Resent-Date: Tue, 14 Nov 2000 10:21:41 -0500 (EST) Resent-Message-Id: <200011141521.KAA04247@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA04221 for ; Tue, 14 Nov 2000 10:21:32 -0500 (EST) 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 KAA14896 for ; Tue, 14 Nov 2000 10:21:32 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id HAA07224 for ; Tue, 14 Nov 2000 07:24:50 -0800 (PST) Received: from mailsj-v1.corp.adobe.com by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id HAA01603; Tue, 14 Nov 2000 07:20:54 -0800 (PST) Received: from brotsky-main ([130.248.193.7]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with ESMTP id G40TAY00.5CE; Tue, 14 Nov 2000 07:20:58 -0800 Message-Id: <4.2.2.20001114064148.02d022b0@mailsj.corp.adobe.com> X-Sender: dbrotsky@mailsj.corp.adobe.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 14 Nov 2000 07:12:54 -0800 To: "Geoffrey M. Clemm" , w3c-dist-auth@w3.org From: "Dan Brotsky" In-Reply-To: <200010242105.RAA08708@tantalum.atria.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: returning the lock token from a LOCK Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4434 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: At 05:05 PM 10/24/00 -0400, Geoffrey M. Clemm wrote: >In section 6.3 of 2518, it says "a lock token is returned by every >successful LOCK operation in the lockdiscovery property in the >response body". > >But then in section 8.10.1, it says "In order to indicate the lock >token associated with a newly created lock, a Lock-Token response >header MUST be included in the response for every successful LOCK >request for a new lock." > >But then in the examples, no Lock-Token response header is included. > >This needs to be cleaned up. > >My personal preference is to go with section 8.10.1, unless there >are servers/clients out there that depend on the section 6.3 >semantics, in which case we probably should require it to appear >in *both* the header and the body (gross). Unfortunately both are useful (and I agree this is gross). The body is necessary because it returns lock expiration charateristics which otherwise would require another round-trip to discover. The header is necessary because the client needs it (in general) to know which lock token the server is granting in response to the request. If a non-exclusive lock is being requested by client A, then other clients may have requested and been granted the same kind of lock during the request-response cycle, in which case the lockdiscovery property will have all the other granted tokens in addition to A's. dan From w3c-dist-auth-request@w3.org Mon Nov 20 14:24:01 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28930 for ; Mon, 20 Nov 2000 14:24:01 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA17847; Mon, 20 Nov 2000 14:10:03 -0500 (EST) Resent-Date: Mon, 20 Nov 2000 14:10:03 -0500 (EST) Resent-Message-Id: <200011201910.OAA17847@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA17825 for ; Mon, 20 Nov 2000 14:09:59 -0500 (EST) Received: from exton3.bentley.com ([207.254.153.70]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA31639 for ; Mon, 20 Nov 2000 14:10:00 -0500 Received: by exton3.bentley.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 14:09:56 -0500 Message-ID: <93C0BE6A6D6AD211BC7400A0C9D8FE87021C9EE7@exton1.bentley.com> From: Adam Klatzkin To: "'w3c-dist-auth@w3.org'" Date: Mon, 20 Nov 2000 14:09:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: WebDAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4435 X-Loop: w3c-dist-auth@w3.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 section 4.5 of RFC 2518 > The property namespace is flat; that is, no hierarchy of properties is explicitly recognized. > Thus, if a property A and a property A/B exist on a resource, there is no recognition of any > relationship between the two properties. . . . > > ... it is not possible to define the same property twice on a single resource, as this would > cause a collision in the resource's property namespace. Example from section 8.2.2 Jim Whitehead Roy Fielding Unless I am interpreting this incorrectly, the example seems to violate the definition of the property namespace as described in section 4.5. Can anybody provide any insight into this? One thought is that maybe Jim Whitehead Roy Fielding is itself the value that should be stored for the Z:authors property? If that is the case then how do I prevent an XML parser from parsing the element tags? Do I have to attempt to rebuild this string from the parsed data and store it? Thanks for any help, Adam Klatzkin Software Engineer Bentley Systems From w3c-dist-auth-request@w3.org Mon Nov 20 22:09:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06804 for ; Mon, 20 Nov 2000 22:09:37 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07599; Mon, 20 Nov 2000 21:59:19 -0500 (EST) Resent-Date: Mon, 20 Nov 2000 21:59:19 -0500 (EST) Resent-Message-Id: <200011210259.VAA07599@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA07576 for ; Mon, 20 Nov 2000 21:59:15 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA08059 for ; Mon, 20 Nov 2000 21:59:13 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id TAA02422; Mon, 20 Nov 2000 19:00:20 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 20 Nov 2000 19:00:20 -0800 From: Greg Stein To: Adam Klatzkin Cc: "'w3c-dist-auth@w3.org'" Message-ID: <20001120190019.Y21426@lyra.org> Mail-Followup-To: Adam Klatzkin , "'w3c-dist-auth@w3.org'" References: <93C0BE6A6D6AD211BC7400A0C9D8FE87021C9EE7@exton1.bentley.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <93C0BE6A6D6AD211BC7400A0C9D8FE87021C9EE7@exton1.bentley.com>; from Adam.Klatzkin@bentley.com on Mon, Nov 20, 2000 at 02:09:40PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: WebDAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4436 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Mon, Nov 20, 2000 at 02:09:40PM -0500, Adam Klatzkin wrote: >... > Example from section 8.2.2 > > > xmlns:Z="http://www.w3.com/standards/z39.50/"> > > > > Jim Whitehead > Roy Fielding > > > > > > > Unless I am interpreting this incorrectly, the example seems to violate the > definition of the property namespace as described in section 4.5. > Can anybody provide any insight into this? > One thought is that maybe > Jim Whitehead > Roy Fielding > is itself the value that should be stored for the Z:authors property? That XML fragment is indeed the property value for Z:authors. > If that is the case then how do I prevent an XML parser from parsing the > element tags? Probably with extreme difficulty. Probably not even possible with most XML parsers. > Do I have to attempt to rebuild this string from the parsed > data and store it? If you want to interpret the value as a string... yes -- you would need to rebuild it. As a concrete example of this behavior: mod_dav parses the above DAV:propertyupdate request into an XML structure. When it goes to store the Z:authors property's value, it reconstructs the string and stores that. So, there is precedent for reconstruction. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 21 04:42:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21468 for ; Tue, 21 Nov 2000 04:42:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA22618; Tue, 21 Nov 2000 04:32:48 -0500 (EST) Resent-Date: Tue, 21 Nov 2000 04:32:48 -0500 (EST) Resent-Message-Id: <200011210932.EAA22618@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA22598 for ; Tue, 21 Nov 2000 04:32:43 -0500 (EST) Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA01255 for ; Tue, 21 Nov 2000 04:32:43 -0500 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id JAA18192 for ; Tue, 21 Nov 2000 09:23:50 GMT Received: from d06mta07.portsmouth.uk.ibm.com (d06mta08_cs0 [9.180.35.21]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id JAA17124 for ; Tue, 21 Nov 2000 09:32:09 GMT Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025699E.00345FDC ; Tue, 21 Nov 2000 09:32:04 +0000 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <8025699E.0033CFF4.00@d06mta07.portsmouth.uk.ibm.com> Date: Tue, 21 Nov 2000 09:25:15 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: WebDAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4437 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: ...and (just to state the obvious), the namespace declaration xmlns:Z="http://www.w3.com/standards/z39.50/"> must also be stored as part of the property. Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 Greg Stein on 2000-11-21 03:00:20 AM Please respond to Greg Stein To: Adam Klatzkin cc: "'w3c-dist-auth@w3.org'" Subject: Re: WebDAV properties On Mon, Nov 20, 2000 at 02:09:40PM -0500, Adam Klatzkin wrote: >... > Example from section 8.2.2 > > > xmlns:Z="http://www.w3.com/standards/z39.50/"> > > > > Jim Whitehead > Roy Fielding > > > > > > > Unless I am interpreting this incorrectly, the example seems to violate the > definition of the property namespace as described in section 4.5. > Can anybody provide any insight into this? > One thought is that maybe > Jim Whitehead > Roy Fielding > is itself the value that should be stored for the Z:authors property? That XML fragment is indeed the property value for Z:authors. > If that is the case then how do I prevent an XML parser from parsing the > element tags? Probably with extreme difficulty. Probably not even possible with most XML parsers. > Do I have to attempt to rebuild this string from the parsed > data and store it? If you want to interpret the value as a string... yes -- you would need to rebuild it. As a concrete example of this behavior: mod_dav parses the above DAV:propertyupdate request into an XML structure. When it goes to store the Z:authors property's value, it reconstructs the string and stores that. So, there is precedent for reconstruction. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Nov 21 12:08:07 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12971 for ; Tue, 21 Nov 2000 12:08:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09507; Tue, 21 Nov 2000 11:43:38 -0500 (EST) Resent-Date: Tue, 21 Nov 2000 11:43:38 -0500 (EST) Resent-Message-Id: <200011211643.LAA09507@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA09483 for ; Tue, 21 Nov 2000 11:43:33 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA11617 for ; Tue, 21 Nov 2000 11:43:32 -0500 Received: from canuck (c239.ppp.tsoft.com [198.144.204.239]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id IAA10034; Tue, 21 Nov 2000 08:43:25 -0800 (PST) From: "Lisa Dusseault" To: "Hartmut Warncke" , "WebDAV WG" Date: Tue, 21 Nov 2000 08:45:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3A101191.18FD3B84@adobe.com> Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4438 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit One more question, because maybe, as Richard Humphreys suggests, "depth infinity" is the problem. Hartmut, does GoLive5 use depth: infinity PROPFIND requests at all? If yes, does it use them for custom property discovery? If not, then we could compromise our way through this by stating that a WebDAV server SHOULD (MUST?) respond to a PROPFIND depth-0 'allprop' request with all custom properties, but that it MAY respond to a PROPFIND depth>0 'allprop' request with a more limited set of properties (suggested to be the non-locking-related properties defined in RFC2518 presently). Would that work? Lisa > -----Original Message----- > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > Sent: Monday, November 13, 2000 8:07 AM > To: Lisa Dusseault > Cc: WebDAV WG > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > To clarify, does the GoLive 5 WebDAV client rely on using > PROPFIND 'allprop' > > requests to get all custom properties on **any** webDAV server? > or against > > a specific webDAV server? > > On **any** WebDAV server. > > > Have you tested this against various servers? > > Does it work with all of them? > > Yes, it's working against IIS and mod_dav for example. > > Best, Hartmut > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke > > > Sent: Monday, November 13, 2000 4:07 AM > > > To: Lisa Dusseault; WebDAV WG > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > Hi all, > > > > > > I have major concerns regarding the change of the response > on a PROPFIND > > > 'allprop' request in the way you described it. > > > > > > Such a change would be *v e r y harmful* for the GoLive 5 > > > WebDAV client. > > > When we send a PROPFIND 'allprop' request we expect all > > > properties which are > > > defined on the resource, especially the Lockproperties and all custom > > > properties defined by GoLive 5 (which we have PROPPATCHED before). > > > > > > We are probably able to replace PROPFIND 'allprop' requests by > > > PROPFIND 'prop' > > > requests in future GoLive releases (which would be indeed much > > > more efficient) > > > but the suggested change in the protocol would be a *disaster* > > > for GoLive 5 > > > which is already in the box. > > > > > > Best, Hartmut > > > > > > > > > Lisa Dusseault wrote: > > > > > > > Past discussions have shown that servers frequently have trouble > > > > implementing PROPFIND 'allprop'. Jim asked me to summarize the past > > > > discussion & list the open issues so that we can get this > > > fixed, if it can > > > > be fixed, in revisions to 2518. > > > > > > > > There are already cases where not all properties will be returned: > > > > RFC2518: "In the case of allprop and propname, if a principal > > > does not have > > > > the > > > > right to know whether a particular property exists then > the property > > > > should be silently excluded from the response." > > > > > > > > John Stracke's proposal for reducing/specifying the scope of > > > 'allprop', and > > > > discussion of the motivation: > > > > - > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > > > - > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > > > > > It has been a point of discussion for Advanced Collections: > > > > - > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > > > "Clients need to know whether the property is computed on > the fly before > > > > requesting it. There is no way to find out. The impact of > > > computing on the > > > > fly is especially significant when a client requests allprop. > > > There may be > > > > other properties that are computed on the fly as well. > DAV:getetag is > > > > computed, and some versioning history properties may also > be computed." > > > > > > > > Also in Versioning: > > > > - > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > > > "There has also been a massive growth in the number of available DAV > > > properties. PROPFIND allprop operations may lead to very large > > > responses even with Depth: 1, which would slow down performance > > > for users due to network speeds. It might be worthwhile to add this > > > facet to the open issue ALLPROP_AND_COMPUTED." > > > > > > Also in ACLs, Babich argues that clients who request 'allprop' don't > > really > > > want to see the ACL property, thus they ought to specifically > ask for it. > > > - http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > > > Several server implementors have voiced the opinion that 'allprop' should > be > > "put out of its misery" (GMC) or at least weakened. Often this is because > > of standard or custom properties that must be calculated by the server > (e.g. > > 'lockdiscovery'), and the calculation can become extraordinarily expensive > > with an 'allprop' of depth: infinity. > > > > The only server-side argument for keeping 'allprop' is that > server-to-server > > COPY requires it; but if anybody has implemented this yet and can't use > > 'propname' instead, please speak up. > > > > Summary: > > There thus seems to be a consensus among server implementors and those > > designing new features for DAV. What's missing in order to resolve this > > issue for fixing RFC2518 is input from clients. > > > > 1. Is anybody aware of clients that rely on particular properties being > > returned in 'allprop'? If the properties relied upon include any more > than > > the set DAV:{creationdate, displayname, getcontentlanguage, > > getcontentlength, getcontenttype, getetag, getlastmodified} (the > properties > > required for DAV level 1 support) I would be very surprised. Thus, > servers > > may be able to restrict the required property set to this set. > > > > 2. Is anybody aware of clients that rely on 'allprop', rather than > > 'propname', for property discovery? This would be a more serious issue if > > major client implementations actually rely on doing property discovery > using > > 'allprop', and attempt this against various implementations of WebDAV > > servers. > > > > These seem to be our options for modifying RFC2518 (remember, it has to be > a > > simple mod): > > - deprecate 'allprop' and tell clients not to use it, but to use > 'propname' > > instead > > - define 'allprop' to be the set of properties required for DAV level 1 > > support (although servers could freely return more properties if desired) > > - explicitly allow servers to return an error code (507?) for properties > > that were too expensive to calculate for a 'allprop' request, but still > > allowing the client to do property discovery through 'allprop' > > > > Please voice your preferences among these options, objections, or other > > ideas. > > > > thanks, > > Lisa > > Xythos From w3c-dist-auth-request@w3.org Tue Nov 21 23:08:09 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03529 for ; Tue, 21 Nov 2000 23:08:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA13219; Tue, 21 Nov 2000 22:57:13 -0500 (EST) Resent-Date: Tue, 21 Nov 2000 22:57:13 -0500 (EST) Resent-Message-Id: <200011220357.WAA13219@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA13198 for ; Tue, 21 Nov 2000 22:57:09 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA12856 for ; Tue, 21 Nov 2000 22:57:09 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.3/8.9.1) with SMTP id TAA21367 for ; Tue, 21 Nov 2000 19:57:07 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 21 Nov 2000 19:55:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: Looking for Java WebDav clients.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4439 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Anselm Rajendra to the accept2 list. - Jim -----Original Message----- From: Anslem Rajendra [mailto:AnslemR@truespectra.com] Sent: Tuesday, November 21, 2000 2:43 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] Looking for Java WebDav clients.. Hello, My company is investigating the possiblity of creating an asset management soln using webDav. I was looking for any Java webDav clients with source code that may be helpful in this endevour. Would you know if there are any out there. Also, would there be any libraries within Sun's java libraries to support this in the future. Thanks, Anslem. From w3c-dist-auth-request@w3.org Wed Nov 22 01:47:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03047 for ; Wed, 22 Nov 2000 01:47:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA15540; Wed, 22 Nov 2000 01:38:39 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 01:38:39 -0500 (EST) Resent-Message-Id: <200011220638.BAA15540@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA15520 for ; Wed, 22 Nov 2000 01:38:35 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA22167 for ; Wed, 22 Nov 2000 01:38:30 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id WAA04177; Tue, 21 Nov 2000 22:39:29 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Tue, 21 Nov 2000 22:39:29 -0800 From: Greg Stein To: AnslemR@truespectra.com Cc: WebDAV WG , jacob.smullyan@starmedia.net Message-ID: <20001121223928.N21426@lyra.org> Mail-Followup-To: AnslemR@truespectra.com, WebDAV WG , jacob.smullyan@starmedia.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ejw@cse.ucsc.edu on Tue, Nov 21, 2000 at 07:55:36PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: FW: Looking for Java WebDav clients.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4440 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Anslem, Please refer to: http://dav.lyra.org/pipermail/dav-dev/2000-November/001698.html Jacob may have a solution for you. Cheers, -g > -----Original Message----- > From: Anslem Rajendra [mailto:AnslemR@truespectra.com] > Sent: Tuesday, November 21, 2000 2:43 PM > To: 'w3c-dist-auth@w3.org' > Subject: [Moderator Action] Looking for Java WebDav clients.. > > > Hello, > > My company is investigating the possiblity of creating an asset management > soln using webDav. I was looking for any Java webDav clients with source > code that may be helpful in this endevour. Would you know if there are any > out there. Also, would there be any libraries within Sun's java libraries > to support this in the future. > > Thanks, > Anslem. -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 22 03:49:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04631 for ; Wed, 22 Nov 2000 03:49:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA17293; Wed, 22 Nov 2000 03:40:40 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 03:40:40 -0500 (EST) Resent-Message-Id: <200011220840.DAA17293@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA17273 for ; Wed, 22 Nov 2000 03:40:34 -0500 (EST) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA29483 for ; Wed, 22 Nov 2000 03:40:30 -0500 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id IAA20399 for ; Wed, 22 Nov 2000 08:40:02 GMT Received: from eurgbrmg02.eur.xerox.com (eurgbrmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id IAA11004 for ; Wed, 22 Nov 2000 08:39:56 GMT Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by eurgbrmg02.eur.xerox.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 22 Nov 2000 08:39:56 +0000 Received: by eurgbrbh01.emeacinops.xerox.com with Internet Mail Service (5.5.2651.58) id ; Wed, 22 Nov 2000 08:39:56 -0000 Message-ID: From: "Hall, Shaun" To: "'Lisa Dusseault'" , Hartmut Warncke , WebDAV WG Date: Wed, 22 Nov 2000 08:39:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4441 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, We've discussed this and don't think that servers should compromise as you've suggested. Even if you permitted what you've suggested, the response could still potentially be very large (depending on the non-locking properties defined and the number of resources). We feel that the locking properties form only a small number of all the properties stored. If a client issues an "allprop", it should get all the properties defined. Allowing the server to chooose what properties to return seems to convulent the RFC/specification for example: - how would the client know whether it actually received all the properties? - would the client have to make further PROPFIND requests to retrieve the extra properties? If people want to allow the server to return a "subset" of all the properties for an "allprop", the specification should "partition" the potential response "in concrete" so there is no room for interpretation for example: - the server MUST return the WebDAV properties. - the server MAY return all other properties. However, if it chooses to return the non-WebDAV properties, it MUST return all non-WebDAV properties. - if the specification allows servers to choose what properties to return, there must be some well defined mechanism for the client to be able to retrieve the non-returned proprties. People must realise that allowing "allprop" with a depth infinity is going to generate potentially large responses (which could be denial of service attacks). If people don't like this, then consider dropping "infinite" depth requests from the specification. This assumes that it doesn't break existing products and one response for one product isn't necessarily a good response/sample. Regards Shaun Hall Xerox Europe > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: 21 November 2000 16:46 > To: Hartmut Warncke; WebDAV WG > Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage > > > One more question, because maybe, as Richard Humphreys > suggests, "depth > infinity" is the problem. > > Hartmut, does GoLive5 use depth: infinity PROPFIND requests > at all? If yes, > does it use them for custom property discovery? > > If not, then we could compromise our way through this by > stating that a > WebDAV server SHOULD (MUST?) respond to a PROPFIND depth-0 > 'allprop' request > with all custom properties, but that it MAY respond to a > PROPFIND depth>0 > 'allprop' request with a more limited set of properties > (suggested to be the > non-locking-related properties defined in RFC2518 presently). > > Would that work? > > Lisa > > > -----Original Message----- > > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > > Sent: Monday, November 13, 2000 8:07 AM > > To: Lisa Dusseault > > Cc: WebDAV WG > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > To clarify, does the GoLive 5 WebDAV client rely on using > > PROPFIND 'allprop' > > > requests to get all custom properties on **any** webDAV server? > > or against > > > a specific webDAV server? > > > > On **any** WebDAV server. > > > > > Have you tested this against various servers? > > > Does it work with all of them? > > > > Yes, it's working against IIS and mod_dav for example. > > > > Best, Hartmut > > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of > Hartmut Warncke > > > > Sent: Monday, November 13, 2000 4:07 AM > > > > To: Lisa Dusseault; WebDAV WG > > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > > > > > Hi all, > > > > > > > > I have major concerns regarding the change of the response > > on a PROPFIND > > > > 'allprop' request in the way you described it. > > > > > > > > Such a change would be *v e r y harmful* for the GoLive 5 > > > > WebDAV client. > > > > When we send a PROPFIND 'allprop' request we expect all > > > > properties which are > > > > defined on the resource, especially the Lockproperties > and all custom > > > > properties defined by GoLive 5 (which we have > PROPPATCHED before). > > > > > > > > We are probably able to replace PROPFIND 'allprop' requests by > > > > PROPFIND 'prop' > > > > requests in future GoLive releases (which would be indeed much > > > > more efficient) > > > > but the suggested change in the protocol would be a *disaster* > > > > for GoLive 5 > > > > which is already in the box. > > > > > > > > Best, Hartmut > > > > > > > > > > > > Lisa Dusseault wrote: > > > > > > > > > Past discussions have shown that servers frequently > have trouble > > > > > implementing PROPFIND 'allprop'. Jim asked me to > summarize the past > > > > > discussion & list the open issues so that we can get this > > > > fixed, if it can > > > > > be fixed, in revisions to 2518. > > > > > > > > > > There are already cases where not all properties will > be returned: > > > > > RFC2518: "In the case of allprop and propname, if a principal > > > > does not have > > > > > the > > > > > right to know whether a particular property exists then > > the property > > > > > should be silently excluded from the response." > > > > > > > > > > John Stracke's proposal for reducing/specifying the scope of > > > > 'allprop', and > > > > > discussion of the motivation: > > > > > - > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > > > > - > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > > > > > > > It has been a point of discussion for Advanced Collections: > > > > > - > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > > > > "Clients need to know whether the property is computed on > > the fly before > > > > > requesting it. There is no way to find out. The impact of > > > > computing on the > > > > > fly is especially significant when a client requests allprop. > > > > There may be > > > > > other properties that are computed on the fly as well. > > DAV:getetag is > > > > > computed, and some versioning history properties may also > > be computed." > > > > > > > > > > Also in Versioning: > > > > > - > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > > > > "There has also been a massive growth in the number of > available DAV > > > > properties. PROPFIND allprop operations may lead to very large > > > > responses even with Depth: 1, which would slow down performance > > > > for users due to network speeds. It might be > worthwhile to add this > > > > facet to the open issue ALLPROP_AND_COMPUTED." > > > > > > > > Also in ACLs, Babich argues that clients who request > 'allprop' don't > > > really > > > > want to see the ACL property, thus they ought to specifically > > ask for it. > > > > - > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > > > > > Several server implementors have voiced the opinion that 'allprop' > should > > be > > > "put out of its misery" (GMC) or at least weakened. Often this is > because > > > of standard or custom properties that must be calculated > by the server > > (e.g. > > > 'lockdiscovery'), and the calculation can become extraordinarily > expensive > > > with an 'allprop' of depth: infinity. > > > > > > The only server-side argument for keeping 'allprop' is that > > server-to-server > > > COPY requires it; but if anybody has implemented this yet > and can't use > > > 'propname' instead, please speak up. > > > > > > Summary: > > > There thus seems to be a consensus among server > implementors and those > > > designing new features for DAV. What's missing in order > to resolve this > > > issue for fixing RFC2518 is input from clients. > > > > > > 1. Is anybody aware of clients that rely on particular > properties being > > > returned in 'allprop'? If the properties relied upon > include any more > > than > > > the set DAV:{creationdate, displayname, getcontentlanguage, > > > getcontentlength, getcontenttype, getetag, getlastmodified} (the > > properties > > > required for DAV level 1 support) I would be very > surprised. Thus, > > servers > > > may be able to restrict the required property set to this set. > > > > > > 2. Is anybody aware of clients that rely on 'allprop', > rather than > > > 'propname', for property discovery? This would be a more > serious issue > if > > > major client implementations actually rely on doing > property discovery > > using > > > 'allprop', and attempt this against various > implementations of WebDAV > > > servers. > > > > > > These seem to be our options for modifying RFC2518 > (remember, it has to > be > > a > > > simple mod): > > > - deprecate 'allprop' and tell clients not to use it, but to use > > 'propname' > > > instead > > > - define 'allprop' to be the set of properties required > for DAV level 1 > > > support (although servers could freely return more properties if > desired) > > > - explicitly allow servers to return an error code (507?) for > properties > > > that were too expensive to calculate for a 'allprop' > request, but still > > > allowing the client to do property discovery through 'allprop' > > > > > > Please voice your preferences among these options, > objections, or other > > > ideas. > > > > > > thanks, > > > Lisa > > > Xythos > From w3c-dist-auth-request@w3.org Wed Nov 22 04:46:43 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10981 for ; Wed, 22 Nov 2000 04:46:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA18268; Wed, 22 Nov 2000 04:34:06 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 04:34:06 -0500 (EST) Resent-Message-Id: <200011220934.EAA18268@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA18244 for ; Wed, 22 Nov 2000 04:34:01 -0500 (EST) Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA00681 for ; Wed, 22 Nov 2000 04:34:02 -0500 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id JAA184234 for ; Wed, 22 Nov 2000 09:19:21 GMT Received: from d06mta07.portsmouth.uk.ibm.com (d06mta08_cs0 [9.180.35.21]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id JAA42794 for ; Wed, 22 Nov 2000 09:33:25 GMT Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025699F.00347AEA ; Wed, 22 Nov 2000 09:33:13 +0000 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <8025699F.00347928.00@d06mta07.portsmouth.uk.ibm.com> Date: Wed, 22 Nov 2000 09:33:08 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: FW: Looking for Java WebDav clients.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4442 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Anselm, Take a look at: http://www.alphaworks.ibm.com/tech/DAV4J Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 "Jim Whitehead" on 2000-11-22 03:55:36 AM Please respond to "Jim Whitehead" To: "WebDAV WG" cc: Subject: FW: Looking for Java WebDav clients.. Accidentally caught by the spam filter. I've added Anselm Rajendra to the accept2 list. - Jim -----Original Message----- From: Anslem Rajendra [mailto:AnslemR@truespectra.com] Sent: Tuesday, November 21, 2000 2:43 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] Looking for Java WebDav clients.. Hello, My company is investigating the possiblity of creating an asset management soln using webDav. I was looking for any Java webDav clients with source code that may be helpful in this endevour. Would you know if there are any out there. Also, would there be any libraries within Sun's java libraries to support this in the future. Thanks, Anslem. From w3c-dist-auth-request@w3.org Wed Nov 22 05:24:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15090 for ; Wed, 22 Nov 2000 05:24:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19371; Wed, 22 Nov 2000 05:13:02 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 05:13:02 -0500 (EST) Resent-Message-Id: <200011221013.FAA19371@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19349 for ; Wed, 22 Nov 2000 05:12:58 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA02975 for ; Wed, 22 Nov 2000 05:12:48 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id CAA04303; Wed, 22 Nov 2000 02:13:54 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 22 Nov 2000 02:13:54 -0800 From: Greg Stein To: Tim_Ellison@uk.ibm.com Cc: w3c-dist-auth@w3.org Message-ID: <20001122021354.R21426@lyra.org> Mail-Followup-To: Tim_Ellison@uk.ibm.com, w3c-dist-auth@w3.org References: <8025699F.00347928.00@d06mta07.portsmouth.uk.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <8025699F.00347928.00@d06mta07.portsmouth.uk.ibm.com>; from Tim_Ellison@uk.ibm.com on Wed, Nov 22, 2000 at 09:33:08AM +0000 X-URL: http://www.lyra.org/greg/ Subject: Re: FW: Looking for Java WebDav clients.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4443 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Tim, Does that come with source code yet? (Anselm asked for source) I know that, in the past, DAV4J was just compiled Java classes. Has that changed now? Cheers, -g On Wed, Nov 22, 2000 at 09:33:08AM +0000, Tim_Ellison@uk.ibm.com wrote: > > > Anselm, > > Take a look at: > http://www.alphaworks.ibm.com/tech/DAV4J > > > Regards, > > Tim Ellison > Java Technology Centre, MP146 > IBM UK Laboratory, Hursley Park, Winchester, UK. > tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 > > > "Jim Whitehead" on 2000-11-22 03:55:36 AM > > Please respond to "Jim Whitehead" > > To: "WebDAV WG" > cc: > Subject: FW: Looking for Java WebDav clients.. > > > > > Accidentally caught by the spam filter. I've added Anselm Rajendra to the > accept2 list. > > - Jim > > -----Original Message----- > From: Anslem Rajendra [mailto:AnslemR@truespectra.com] > Sent: Tuesday, November 21, 2000 2:43 PM > To: 'w3c-dist-auth@w3.org' > Subject: [Moderator Action] Looking for Java WebDav clients.. > > > Hello, > > My company is investigating the possiblity of creating an asset management > soln using webDav. I was looking for any Java webDav clients with source > code that may be helpful in this endevour. Would you know if there are any > out there. Also, would there be any libraries within Sun's java libraries > to support this in the future. > > Thanks, > Anslem. > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 22 05:35:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16458 for ; Wed, 22 Nov 2000 05:35:50 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA19892; Wed, 22 Nov 2000 05:27:03 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 05:27:03 -0500 (EST) Resent-Message-Id: <200011221027.FAA19892@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA19868 for ; Wed, 22 Nov 2000 05:26:56 -0500 (EST) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA04028 for ; Wed, 22 Nov 2000 05:26:53 -0500 From: Tim_Ellison@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id KAA115656; Wed, 22 Nov 2000 10:12:42 GMT Received: from d06mta07.portsmouth.uk.ibm.com (d06mta08_cs0 [9.180.35.21]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id KAA66370; Wed, 22 Nov 2000 10:26:04 GMT Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025699F.00394E2F ; Wed, 22 Nov 2000 10:25:55 +0000 X-Lotus-FromDomain: IBMGB To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <8025699F.00394931.00@d06mta07.portsmouth.uk.ibm.com> Date: Wed, 22 Nov 2000 10:25:40 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: FW: Looking for Java WebDav clients.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4444 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Greg, Yep, check out the announcement http://lists.w3.org/Archives/Public/w3c-dist-auth/2000OctDec/0021.html Regards, Tim From: Greg Stein To: Tim Ellison/UK/IBM@IBMGB cc: w3c-dist-auth@w3.org Subject: Re: FW: Looking for Java WebDav clients.. Tim, Does that come with source code yet? (Anselm asked for source) I know that, in the past, DAV4J was just compiled Java classes. Has that changed now? Cheers, -g On Wed, Nov 22, 2000 at 09:33:08AM +0000, Tim_Ellison@uk.ibm.com wrote: > > > Anselm, > > Take a look at: > http://www.alphaworks.ibm.com/tech/DAV4J > > > Regards, > > Tim Ellison > Java Technology Centre, MP146 > IBM UK Laboratory, Hursley Park, Winchester, UK. > tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 > > > "Jim Whitehead" on 2000-11-22 03:55:36 AM > > Please respond to "Jim Whitehead" > > To: "WebDAV WG" > cc: > Subject: FW: Looking for Java WebDav clients.. > > > > > Accidentally caught by the spam filter. I've added Anselm Rajendra to the > accept2 list. > > - Jim > > -----Original Message----- > From: Anslem Rajendra [mailto:AnslemR@truespectra.com] > Sent: Tuesday, November 21, 2000 2:43 PM > To: 'w3c-dist-auth@w3.org' > Subject: [Moderator Action] Looking for Java WebDav clients.. > > > Hello, > > My company is investigating the possiblity of creating an asset management > soln using webDav. I was looking for any Java webDav clients with source > code that may be helpful in this endevour. Would you know if there are any > out there. Also, would there be any libraries within Sun's java libraries > to support this in the future. > > Thanks, > Anslem. > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 22 08:23:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12814 for ; Wed, 22 Nov 2000 08:23:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA25573; Wed, 22 Nov 2000 08:13:28 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 08:13:28 -0500 (EST) Resent-Message-Id: <200011221313.IAA25573@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA25553 for ; Wed, 22 Nov 2000 08:13:22 -0500 (EST) 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 IAA16364 for ; Wed, 22 Nov 2000 08:13:22 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id FAA22617; Wed, 22 Nov 2000 05:16:08 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id FAA17869; Wed, 22 Nov 2000 05:12:13 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id OAA25490; Wed, 22 Nov 2000 14:07:52 +0100 (MET) Message-ID: <3A1BC630.32C1974D@adobe.com> Date: Wed, 22 Nov 2000 14:12:16 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Lisa Dusseault CC: WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4445 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, > One more question, because maybe, as Richard Humphreys suggests, "depth > infinity" is the problem. > > Hartmut, does GoLive5 use depth: infinity PROPFIND requests at all? If yes, > does it use them for custom property discovery? Yes, GoLive uses those infinity requests because it's a very effiicient way to synchronize the WebDAV server content with the content of a site on the local machine with *o n e* network request. We are requesting build-in DAV properties (like "getlastmodified" or "lockdiscovery") as well as custom properties (which were PROPPATCHED by GoLive before) with depth infinity. To my mind depth infinity requests are -from the client perspective - a very efficient and interesting WebDAV feature. Dropping infinite requests would break GoLive 5! By the way if a server would be allowed to refuse depth infinity requests (like mod_dav with its "DavDepthInfinity" flag in its configuration file), the client needs a mechanism to figure out if the server is willing to respond to depth infinity requests or not. This mechanism has to be precisely defined by RFC2518. > If not, then we could compromise our way through this by stating that a > WebDAV server SHOULD (MUST?) respond to a PROPFIND depth-0 'allprop' request > with all custom properties, but that it MAY respond to a PROPFIND depth>0 > 'allprop' request with a more limited set of properties (suggested to be the > non-locking-related properties defined in RFC2518 presently). > > Would that work? I think "allprop" should always return all properties (custom and DAV build-in). Perhaps it makes sense to drop PROPFIND-ALLPROP requests with depth infinity but please keep the PROPFIND-PROP requests with depth infinity because they are a very powerful and efficient instrument. Dropping those requests would lead us -in some situations- into a time consuming disaster with a huge amount of network traffic. Best, Hartmut > > -----Original Message----- > > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > > Sent: Monday, November 13, 2000 8:07 AM > > To: Lisa Dusseault > > Cc: WebDAV WG > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > To clarify, does the GoLive 5 WebDAV client rely on using > > PROPFIND 'allprop' > > > requests to get all custom properties on **any** webDAV server? > > or against > > > a specific webDAV server? > > > > On **any** WebDAV server. > > > > > Have you tested this against various servers? > > > Does it work with all of them? > > > > Yes, it's working against IIS and mod_dav for example. > > > > Best, Hartmut > > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke > > > > Sent: Monday, November 13, 2000 4:07 AM > > > > To: Lisa Dusseault; WebDAV WG > > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > > > > > Hi all, > > > > > > > > I have major concerns regarding the change of the response > > on a PROPFIND > > > > 'allprop' request in the way you described it. > > > > > > > > Such a change would be *v e r y harmful* for the GoLive 5 > > > > WebDAV client. > > > > When we send a PROPFIND 'allprop' request we expect all > > > > properties which are > > > > defined on the resource, especially the Lockproperties and all custom > > > > properties defined by GoLive 5 (which we have PROPPATCHED before). > > > > > > > > We are probably able to replace PROPFIND 'allprop' requests by > > > > PROPFIND 'prop' > > > > requests in future GoLive releases (which would be indeed much > > > > more efficient) > > > > but the suggested change in the protocol would be a *disaster* > > > > for GoLive 5 > > > > which is already in the box. > > > > > > > > Best, Hartmut > > > > > > > > > > > > Lisa Dusseault wrote: > > > > > > > > > Past discussions have shown that servers frequently have trouble > > > > > implementing PROPFIND 'allprop'. Jim asked me to summarize the past > > > > > discussion & list the open issues so that we can get this > > > > fixed, if it can > > > > > be fixed, in revisions to 2518. > > > > > > > > > > There are already cases where not all properties will be returned: > > > > > RFC2518: "In the case of allprop and propname, if a principal > > > > does not have > > > > > the > > > > > right to know whether a particular property exists then > > the property > > > > > should be silently excluded from the response." > > > > > > > > > > John Stracke's proposal for reducing/specifying the scope of > > > > 'allprop', and > > > > > discussion of the motivation: > > > > > - > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > > > > - > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > > > > > > > It has been a point of discussion for Advanced Collections: > > > > > - > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > > > > "Clients need to know whether the property is computed on > > the fly before > > > > > requesting it. There is no way to find out. The impact of > > > > computing on the > > > > > fly is especially significant when a client requests allprop. > > > > There may be > > > > > other properties that are computed on the fly as well. > > DAV:getetag is > > > > > computed, and some versioning history properties may also > > be computed." > > > > > > > > > > Also in Versioning: > > > > > - > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > > > > "There has also been a massive growth in the number of available DAV > > > > properties. PROPFIND allprop operations may lead to very large > > > > responses even with Depth: 1, which would slow down performance > > > > for users due to network speeds. It might be worthwhile to add this > > > > facet to the open issue ALLPROP_AND_COMPUTED." > > > > > > > > Also in ACLs, Babich argues that clients who request 'allprop' don't > > > really > > > > want to see the ACL property, thus they ought to specifically > > ask for it. > > > > - > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > > > > > Several server implementors have voiced the opinion that 'allprop' > should > > be > > > "put out of its misery" (GMC) or at least weakened. Often this is > because > > > of standard or custom properties that must be calculated by the server > > (e.g. > > > 'lockdiscovery'), and the calculation can become extraordinarily > expensive > > > with an 'allprop' of depth: infinity. > > > > > > The only server-side argument for keeping 'allprop' is that > > server-to-server > > > COPY requires it; but if anybody has implemented this yet and can't use > > > 'propname' instead, please speak up. > > > > > > Summary: > > > There thus seems to be a consensus among server implementors and those > > > designing new features for DAV. What's missing in order to resolve this > > > issue for fixing RFC2518 is input from clients. > > > > > > 1. Is anybody aware of clients that rely on particular properties being > > > returned in 'allprop'? If the properties relied upon include any more > > than > > > the set DAV:{creationdate, displayname, getcontentlanguage, > > > getcontentlength, getcontenttype, getetag, getlastmodified} (the > > properties > > > required for DAV level 1 support) I would be very surprised. Thus, > > servers > > > may be able to restrict the required property set to this set. > > > > > > 2. Is anybody aware of clients that rely on 'allprop', rather than > > > 'propname', for property discovery? This would be a more serious issue > if > > > major client implementations actually rely on doing property discovery > > using > > > 'allprop', and attempt this against various implementations of WebDAV > > > servers. > > > > > > These seem to be our options for modifying RFC2518 (remember, it has to > be > > a > > > simple mod): > > > - deprecate 'allprop' and tell clients not to use it, but to use > > 'propname' > > > instead > > > - define 'allprop' to be the set of properties required for DAV level 1 > > > support (although servers could freely return more properties if > desired) > > > - explicitly allow servers to return an error code (507?) for > properties > > > that were too expensive to calculate for a 'allprop' request, but still > > > allowing the client to do property discovery through 'allprop' > > > > > > Please voice your preferences among these options, objections, or other > > > ideas. > > > > > > thanks, > > > Lisa > > > Xythos From w3c-dist-auth-request@w3.org Wed Nov 22 11:36:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21788 for ; Wed, 22 Nov 2000 11:36:14 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA04466; Wed, 22 Nov 2000 11:17:52 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 11:17:52 -0500 (EST) Resent-Message-Id: <200011221617.LAA04466@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA04424 for ; Wed, 22 Nov 2000 11:17:39 -0500 (EST) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA04816 for ; Wed, 22 Nov 2000 11:17:34 -0500 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id QAA21548 for ; Wed, 22 Nov 2000 16:17:17 GMT Received: from eurgbrmg02.eur.xerox.com (eurgbrmg02.eur.xerox.com [13.202.65.254]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id PAA26322 for ; Wed, 22 Nov 2000 15:58:03 GMT Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by eurgbrmg02.eur.xerox.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 22 Nov 2000 15:27:52 +0000 Received: by eurgbrbh01.emeacinops.xerox.com with Internet Mail Service (5.5.2651.58) id ; Wed, 22 Nov 2000 15:27:50 -0000 Message-ID: From: "Hall, Shaun" To: "'Hartmut Warncke'" , Lisa Dusseault Cc: WebDAV WG Date: Wed, 22 Nov 2000 15:27:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4446 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > -----Original Message----- > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > Sent: 22 November 2000 13:12 > To: Lisa Dusseault > Cc: WebDAV WG > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > Lisa, > > > > One more question, because maybe, as Richard Humphreys > suggests, "depth > > infinity" is the problem. > > > > Hartmut, does GoLive5 use depth: infinity PROPFIND requests > at all? If yes, > > does it use them for custom property discovery? > > Yes, GoLive uses those infinity requests because it's a very > effiicient way to > synchronize the WebDAV server content with the content of a > site on the local > machine with *o n e* network request. We are requesting build-in DAV > properties (like "getlastmodified" or "lockdiscovery") as > well as custom > properties (which were PROPPATCHED by GoLive before) with > depth infinity. > > To my mind depth infinity requests are -from the client > perspective - a very > efficient and interesting WebDAV feature. > Dropping infinite requests would break GoLive 5! The implications of PROPFIND with an infinite depth affect both the server and/or the client. Supposing you have a large WebDAV enabled repository. The PROPFIND request (a few hundred bytes) could potentially mean that (tens of) GBs of data is to be returned. Even if the server could generate such a large response (which is a feat in its own right), it will load the network, and what will happen when the client receives it? Pity the poor user sitting there for a long time (hours?), only to be told "timed out" or "out of memory" or something similar. > > By the way if a server would be allowed to refuse depth > infinity requests (like > mod_dav with its "DavDepthInfinity" flag in its configuration > file), the client > needs a mechanism to figure out if the server is willing to > respond to depth > infinity requests or not. This mechanism has to be precisely > defined by RFC2518. > Changing the specification could break existing products, which is a bad thing. Backwards compatibilty should be maintained. We think the way forward for the WebDAV specification is to allow servers the ability to refuse such requests and inform the client. A mechanism should be defined for the client to understand this. If the client received a response which basically stated that the server was refusing to service an infinite depth request, it could issue multiple requests with a Depth:1. Regards Shaun Hall Xerox Europe > > > > If not, then we could compromise our way through this by > stating that a > > WebDAV server SHOULD (MUST?) respond to a PROPFIND depth-0 > 'allprop' request > > with all custom properties, but that it MAY respond to a > PROPFIND depth>0 > > 'allprop' request with a more limited set of properties > (suggested to be the > > non-locking-related properties defined in RFC2518 presently). > > > > Would that work? > > I think "allprop" should always return all properties (custom > and DAV build-in). > Perhaps it makes sense to drop PROPFIND-ALLPROP requests with > depth infinity but > please keep the PROPFIND-PROP requests with depth infinity > because they are a > very powerful and efficient instrument. Dropping those > requests would lead us > -in some situations- into a time consuming disaster with a > huge amount of > network traffic. > > Best, Hartmut > > > > > -----Original Message----- > > > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > > > Sent: Monday, November 13, 2000 8:07 AM > > > To: Lisa Dusseault > > > Cc: WebDAV WG > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > > > > > To clarify, does the GoLive 5 WebDAV client rely on using > > > PROPFIND 'allprop' > > > > requests to get all custom properties on **any** webDAV server? > > > or against > > > > a specific webDAV server? > > > > > > On **any** WebDAV server. > > > > > > > Have you tested this against various servers? > > > > Does it work with all of them? > > > > > > Yes, it's working against IIS and mod_dav for example. > > > > > > Best, Hartmut > > > > > > > > > > > -----Original Message----- > > > > > From: w3c-dist-auth-request@w3.org > > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of > Hartmut Warncke > > > > > Sent: Monday, November 13, 2000 4:07 AM > > > > > To: Lisa Dusseault; WebDAV WG > > > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I have major concerns regarding the change of the response > > > on a PROPFIND > > > > > 'allprop' request in the way you described it. > > > > > > > > > > Such a change would be *v e r y harmful* for the GoLive 5 > > > > > WebDAV client. > > > > > When we send a PROPFIND 'allprop' request we expect all > > > > > properties which are > > > > > defined on the resource, especially the > Lockproperties and all custom > > > > > properties defined by GoLive 5 (which we have > PROPPATCHED before). > > > > > > > > > > We are probably able to replace PROPFIND 'allprop' requests by > > > > > PROPFIND 'prop' > > > > > requests in future GoLive releases (which would be indeed much > > > > > more efficient) > > > > > but the suggested change in the protocol would be a > *disaster* > > > > > for GoLive 5 > > > > > which is already in the box. > > > > > > > > > > Best, Hartmut > > > > > > > > > > > > > > > Lisa Dusseault wrote: > > > > > > > > > > > Past discussions have shown that servers frequently > have trouble > > > > > > implementing PROPFIND 'allprop'. Jim asked me to > summarize the past > > > > > > discussion & list the open issues so that we can get this > > > > > fixed, if it can > > > > > > be fixed, in revisions to 2518. > > > > > > > > > > > > There are already cases where not all properties > will be returned: > > > > > > RFC2518: "In the case of allprop and propname, if a > principal > > > > > does not have > > > > > > the > > > > > > right to know whether a particular property exists then > > > the property > > > > > > should be silently excluded from the response." > > > > > > > > > > > > John Stracke's proposal for reducing/specifying the scope of > > > > > 'allprop', and > > > > > > discussion of the motivation: > > > > > > - > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > > > > > - > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > > > > > > > > > It has been a point of discussion for Advanced Collections: > > > > > > - > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > > > > > "Clients need to know whether the property is computed on > > > the fly before > > > > > > requesting it. There is no way to find out. The impact of > > > > > computing on the > > > > > > fly is especially significant when a client > requests allprop. > > > > > There may be > > > > > > other properties that are computed on the fly as well. > > > DAV:getetag is > > > > > > computed, and some versioning history properties may also > > > be computed." > > > > > > > > > > > > Also in Versioning: > > > > > > - > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > > > > > "There has also been a massive growth in the number > of available DAV > > > > > properties. PROPFIND allprop operations may lead to > very large > > > > > responses even with Depth: 1, which would slow down > performance > > > > > for users due to network speeds. It might be > worthwhile to add this > > > > > facet to the open issue ALLPROP_AND_COMPUTED." > > > > > > > > > > Also in ACLs, Babich argues that clients who request > 'allprop' don't > > > > really > > > > > want to see the ACL property, thus they ought to specifically > > > ask for it. > > > > > - > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > > > > > > > Several server implementors have voiced the opinion > that 'allprop' > > should > > > be > > > > "put out of its misery" (GMC) or at least weakened. > Often this is > > because > > > > of standard or custom properties that must be > calculated by the server > > > (e.g. > > > > 'lockdiscovery'), and the calculation can become extraordinarily > > expensive > > > > with an 'allprop' of depth: infinity. > > > > > > > > The only server-side argument for keeping 'allprop' is that > > > server-to-server > > > > COPY requires it; but if anybody has implemented this > yet and can't use > > > > 'propname' instead, please speak up. > > > > > > > > Summary: > > > > There thus seems to be a consensus among server > implementors and those > > > > designing new features for DAV. What's missing in > order to resolve this > > > > issue for fixing RFC2518 is input from clients. > > > > > > > > 1. Is anybody aware of clients that rely on particular > properties being > > > > returned in 'allprop'? If the properties relied upon > include any more > > > than > > > > the set DAV:{creationdate, displayname, getcontentlanguage, > > > > getcontentlength, getcontenttype, getetag, getlastmodified} (the > > > properties > > > > required for DAV level 1 support) I would be very > surprised. Thus, > > > servers > > > > may be able to restrict the required property set to this set. > > > > > > > > 2. Is anybody aware of clients that rely on 'allprop', > rather than > > > > 'propname', for property discovery? This would be a > more serious issue > > if > > > > major client implementations actually rely on doing > property discovery > > > using > > > > 'allprop', and attempt this against various > implementations of WebDAV > > > > servers. > > > > > > > > These seem to be our options for modifying RFC2518 > (remember, it has to > > be > > > a > > > > simple mod): > > > > - deprecate 'allprop' and tell clients not to use it, > but to use > > > 'propname' > > > > instead > > > > - define 'allprop' to be the set of properties > required for DAV level 1 > > > > support (although servers could freely return more properties if > > desired) > > > > - explicitly allow servers to return an error code (507?) for > > properties > > > > that were too expensive to calculate for a 'allprop' > request, but still > > > > allowing the client to do property discovery through 'allprop' > > > > > > > > Please voice your preferences among these options, > objections, or other > > > > ideas. > > > > > > > > thanks, > > > > Lisa > > > > Xythos > From w3c-dist-auth-request@w3.org Wed Nov 22 12:35:21 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03540 for ; Wed, 22 Nov 2000 12:35:20 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07881; Wed, 22 Nov 2000 12:13:23 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 12:13:23 -0500 (EST) Resent-Message-Id: <200011221713.MAA07881@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA07854 for ; Wed, 22 Nov 2000 12:13:17 -0500 (EST) 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 MAA10811 for ; Wed, 22 Nov 2000 12:13:17 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id JAA13252; Wed, 22 Nov 2000 09:02:35 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id IAA01634; Wed, 22 Nov 2000 08:58:41 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id RAA08019; Wed, 22 Nov 2000 17:54:02 +0100 (MET) Message-ID: <3A1BFB32.778D55BF@adobe.com> Date: Wed, 22 Nov 2000 17:58:26 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Hall, Shaun" , WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4447 X-Loop: w3c-dist-auth@w3.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 implications of PROPFIND with an infinite depth affect both the server > and/or the client. Supposing you have a large WebDAV enabled repository. The > PROPFIND request (a few hundred bytes) could potentially mean that (tens of) > GBs of data is to be returned. Even if the server could generate such a > large response (which is a feat in its own right), it will load the network, > and what will happen when the client receives it? Pity the poor user sitting > there for a long time (hours?), only to be told "timed out" or "out of > memory" or something similar. Yes, of course, I completely understand your point of view. But as a matter of fact we like this "depth infinity" feature very much because we can use it in a very efficient way in some situations and therefore we are struggleing so hard for keeping that feature. > Changing the specification could break existing products, which is a bad > thing. Backwards compatibilty should be maintained. Good to hear that. But I am not quite sure how you will do that because if a server has the possibility to refuse a depth infinity request GoLive 5 will not be able to handle that situation (synchronization of client and server content will not work anymore). > We think the way forward for the WebDAV specification is to allow servers > the ability to refuse such requests and inform the client. A mechanism > should be defined for the client to understand this. If the client received > a response which basically stated that the server was refusing to service an > infinite depth request, it could issue multiple requests with a Depth:1. If you have to synchronize a very large site with thousands of files, replacing depth infinity requests by depth 1 requests would be a huge performance disaster for us. Best, Hartmut From w3c-dist-auth-request@w3.org Wed Nov 22 13:51:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26363 for ; Wed, 22 Nov 2000 13:51:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12538; Wed, 22 Nov 2000 13:38:27 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 13:38:27 -0500 (EST) Resent-Message-Id: <200011221838.NAA12538@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA12515 for ; Wed, 22 Nov 2000 13:38:23 -0500 (EST) Received: from mt.fiberone.net (h209-50-64-162.mt.sfl.net [209.50.64.162]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA19539 for ; Wed, 22 Nov 2000 13:38:22 -0500 Received: by h209-50-64-162.mt.fiberone.net id <119126>; Wed, 22 Nov 2000 13:31:16 -0500 Message-Id: <00Nov22.133116est.119126@h209-50-64-162.mt.fiberone.net> From: "Peterson, Byron - [RHX]" To: "'Hartmut Warncke'" , "Peterson, Byron - [RHX]" Cc: WebDAV WG Date: Wed, 22 Nov 2000 10:43:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4448 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: could you please tell me how to unsubscribe to this list??? Thanks... -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] Sent: Wednesday, November 22, 2000 8:12 AM To: Byron.Peterson@trh.cgi.ca Cc: WebDAV WG Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Lisa, > One more question, because maybe, as Richard Humphreys suggests, "depth > infinity" is the problem. > > Hartmut, does GoLive5 use depth: infinity PROPFIND requests at all? If yes, > does it use them for custom property discovery? Yes, GoLive uses those infinity requests because it's a very effiicient way to synchronize the WebDAV server content with the content of a site on the local machine with *o n e* network request. We are requesting build-in DAV properties (like "getlastmodified" or "lockdiscovery") as well as custom properties (which were PROPPATCHED by GoLive before) with depth infinity. To my mind depth infinity requests are -from the client perspective - a very efficient and interesting WebDAV feature. Dropping infinite requests would break GoLive 5! By the way if a server would be allowed to refuse depth infinity requests (like mod_dav with its "DavDepthInfinity" flag in its configuration file), the client needs a mechanism to figure out if the server is willing to respond to depth infinity requests or not. This mechanism has to be precisely defined by RFC2518. > If not, then we could compromise our way through this by stating that a > WebDAV server SHOULD (MUST?) respond to a PROPFIND depth-0 'allprop' request > with all custom properties, but that it MAY respond to a PROPFIND depth>0 > 'allprop' request with a more limited set of properties (suggested to be the > non-locking-related properties defined in RFC2518 presently). > > Would that work? I think "allprop" should always return all properties (custom and DAV build-in). Perhaps it makes sense to drop PROPFIND-ALLPROP requests with depth infinity but please keep the PROPFIND-PROP requests with depth infinity because they are a very powerful and efficient instrument. Dropping those requests would lead us -in some situations- into a time consuming disaster with a huge amount of network traffic. Best, Hartmut > > -----Original Message----- > > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > > Sent: Monday, November 13, 2000 8:07 AM > > To: Lisa Dusseault > > Cc: WebDAV WG > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > To clarify, does the GoLive 5 WebDAV client rely on using > > PROPFIND 'allprop' > > > requests to get all custom properties on **any** webDAV server? > > or against > > > a specific webDAV server? > > > > On **any** WebDAV server. > > > > > Have you tested this against various servers? > > > Does it work with all of them? > > > > Yes, it's working against IIS and mod_dav for example. > > > > Best, Hartmut > > > > > > > > -----Original Message----- > > > > From: w3c-dist-auth-request@w3.org > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke > > > > Sent: Monday, November 13, 2000 4:07 AM > > > > To: Lisa Dusseault; WebDAV WG > > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > > > > > Hi all, > > > > > > > > I have major concerns regarding the change of the response > > on a PROPFIND > > > > 'allprop' request in the way you described it. > > > > > > > > Such a change would be *v e r y harmful* for the GoLive 5 > > > > WebDAV client. > > > > When we send a PROPFIND 'allprop' request we expect all > > > > properties which are > > > > defined on the resource, especially the Lockproperties and all custom > > > > properties defined by GoLive 5 (which we have PROPPATCHED before). > > > > > > > > We are probably able to replace PROPFIND 'allprop' requests by > > > > PROPFIND 'prop' > > > > requests in future GoLive releases (which would be indeed much > > > > more efficient) > > > > but the suggested change in the protocol would be a *disaster* > > > > for GoLive 5 > > > > which is already in the box. > > > > > > > > Best, Hartmut > > > > > > > > > > > > Lisa Dusseault wrote: > > > > > > > > > Past discussions have shown that servers frequently have trouble > > > > > implementing PROPFIND 'allprop'. Jim asked me to summarize the past > > > > > discussion & list the open issues so that we can get this > > > > fixed, if it can > > > > > be fixed, in revisions to 2518. > > > > > > > > > > There are already cases where not all properties will be returned: > > > > > RFC2518: "In the case of allprop and propname, if a principal > > > > does not have > > > > > the > > > > > right to know whether a particular property exists then > > the property > > > > > should be silently excluded from the response." > > > > > > > > > > John Stracke's proposal for reducing/specifying the scope of > > > > 'allprop', and > > > > > discussion of the motivation: > > > > > - > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > > > > - > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > > > > > > > It has been a point of discussion for Advanced Collections: > > > > > - > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > > > > "Clients need to know whether the property is computed on > > the fly before > > > > > requesting it. There is no way to find out. The impact of > > > > computing on the > > > > > fly is especially significant when a client requests allprop. > > > > There may be > > > > > other properties that are computed on the fly as well. > > DAV:getetag is > > > > > computed, and some versioning history properties may also > > be computed." > > > > > > > > > > Also in Versioning: > > > > > - > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > > > > "There has also been a massive growth in the number of available DAV > > > > properties. PROPFIND allprop operations may lead to very large > > > > responses even with Depth: 1, which would slow down performance > > > > for users due to network speeds. It might be worthwhile to add this > > > > facet to the open issue ALLPROP_AND_COMPUTED." > > > > > > > > Also in ACLs, Babich argues that clients who request 'allprop' don't > > > really > > > > want to see the ACL property, thus they ought to specifically > > ask for it. > > > > - > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > > > > > Several server implementors have voiced the opinion that 'allprop' > should > > be > > > "put out of its misery" (GMC) or at least weakened. Often this is > because > > > of standard or custom properties that must be calculated by the server > > (e.g. > > > 'lockdiscovery'), and the calculation can become extraordinarily > expensive > > > with an 'allprop' of depth: infinity. > > > > > > The only server-side argument for keeping 'allprop' is that > > server-to-server > > > COPY requires it; but if anybody has implemented this yet and can't use > > > 'propname' instead, please speak up. > > > > > > Summary: > > > There thus seems to be a consensus among server implementors and those > > > designing new features for DAV. What's missing in order to resolve this > > > issue for fixing RFC2518 is input from clients. > > > > > > 1. Is anybody aware of clients that rely on particular properties being > > > returned in 'allprop'? If the properties relied upon include any more > > than > > > the set DAV:{creationdate, displayname, getcontentlanguage, > > > getcontentlength, getcontenttype, getetag, getlastmodified} (the > > properties > > > required for DAV level 1 support) I would be very surprised. Thus, > > servers > > > may be able to restrict the required property set to this set. > > > > > > 2. Is anybody aware of clients that rely on 'allprop', rather than > > > 'propname', for property discovery? This would be a more serious issue > if > > > major client implementations actually rely on doing property discovery > > using > > > 'allprop', and attempt this against various implementations of WebDAV > > > servers. > > > > > > These seem to be our options for modifying RFC2518 (remember, it has to > be > > a > > > simple mod): > > > - deprecate 'allprop' and tell clients not to use it, but to use > > 'propname' > > > instead > > > - define 'allprop' to be the set of properties required for DAV level 1 > > > support (although servers could freely return more properties if > desired) > > > - explicitly allow servers to return an error code (507?) for > properties > > > that were too expensive to calculate for a 'allprop' request, but still > > > allowing the client to do property discovery through 'allprop' > > > > > > Please voice your preferences among these options, objections, or other > > > ideas. > > > > > > thanks, > > > Lisa > > > Xythos From w3c-dist-auth-request@w3.org Wed Nov 22 15:25:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25629 for ; Wed, 22 Nov 2000 15:25:27 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17078; Wed, 22 Nov 2000 15:09:00 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 15:09:00 -0500 (EST) Resent-Message-Id: <200011222009.PAA17078@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA17058 for ; Wed, 22 Nov 2000 15:08:56 -0500 (EST) Received: from pop.mainstreet.net (pop.mainstreet.net [207.5.0.4]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28665 for ; Wed, 22 Nov 2000 15:08:57 -0500 Received: from iguana.nuvation.com (iguana.nuvation.com [204.69.220.162]) by pop.mainstreet.net (8.9.2/8.9.2) with ESMTP id MAA15914 for ; Wed, 22 Nov 2000 12:08:48 -0800 (PST) Received: by IGUANA with Internet Mail Service (5.5.2448.0) id ; Wed, 22 Nov 2000 12:09:14 -0800 Message-ID: <3D6283E3E734D411A0AB00104BC7C4A802879A@IGUANA> From: Michael Hermann To: "'w3c-dist-auth@w3.org'" Date: Wed, 22 Nov 2000 12:08:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C054BF.FF4756A0" Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4450 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C054BF.FF4756A0 Content-Type: text/plain; charset="iso-8859-1" unsubscribe (sorry if this goes to the list, I forgot to record the admin address) > -----Original Message----- > From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] > Sent: Wednesday, November 22, 2000 12:00 PM > To: w3c-dist-auth@w3.org > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > I have to agree with Shaun that providing an unbounded > implementation of > 'PROPFIND allprops depth infinity' would be brain dead. > Similarly, moving > the goal posts to say that allprops no longer returns all the > properties > would be 'unfavourable' to existing clients and servers. > > The only tenable position is to allow the server to refuse > the request, > either in its entirety (no all props and/or no depth infinity) or by > allowing it to report partial results (a response status code that > indicates not all properties were returned, and/or collection > members were > not traversed) for a resource. > > IMHO, attempting to synchronize thousands of files with a > single call to > the server is not a fantastic idea. > > Regards, > > Tim > > > Hartmut Warncke on 2000-11-22 04:58:26 PM > > Please respond to Hartmut Warncke > > To: "Hall, Shaun" , WebDAV WG > > cc: > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > The implications of PROPFIND with an infinite depth affect both the > server > > and/or the client. Supposing you have a large WebDAV > enabled repository. > The > > PROPFIND request (a few hundred bytes) could potentially > mean that (tens > of) > > GBs of data is to be returned. Even if the server could > generate such a > > large response (which is a feat in its own right), it will load the > network, > > and what will happen when the client receives it? Pity the poor user > sitting > > there for a long time (hours?), only to be told "timed out" > or "out of > > memory" or something similar. > > Yes, of course, I completely understand your point of view. > But as a matter > of > fact we like this "depth infinity" feature very much because > we can use it > in a > very efficient way in some situations and therefore we are > struggleing so > hard > for keeping that feature. > > > Changing the specification could break existing products, > which is a bad > > thing. Backwards compatibilty should be maintained. > > Good to hear that. But I am not quite sure how you will do > that because if > a > server has the possibility to refuse a depth infinity request > GoLive 5 will > not > be able to handle that situation (synchronization of client and server > content > will not work anymore). > > > We think the way forward for the WebDAV specification is to > allow servers > > the ability to refuse such requests and inform the client. > A mechanism > > should be defined for the client to understand this. If the client > received > > a response which basically stated that the server was > refusing to service > an > > infinite depth request, it could issue multiple requests > with a Depth:1. > > If you have to synchronize a very large site with thousands of files, > replacing > depth infinity requests by depth 1 requests would be a huge > performance > disaster > for us. > > Best, Hartmut > > > > ------_=_NextPart_001_01C054BF.FF4756A0 Content-Type: text/html; charset="iso-8859-1" RE: [RFC2518 Issue] PROPFIND 'allprop' usage

unsubscribe

(sorry if this goes to the list, I forgot to record the admin address)

> -----Original Message-----
> From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
> Sent: Wednesday, November 22, 2000 12:00 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage
>
>
>
>
> I have to agree with Shaun that providing an unbounded
> implementation of
> 'PROPFIND allprops depth infinity' would be brain dead. 
> Similarly, moving
> the goal posts to say that allprops no longer returns all the
> properties
> would be 'unfavourable' to existing clients and servers.
>
> The only tenable position is to allow the server to refuse
> the request,
> either in its entirety (no all props and/or no depth infinity) or by
> allowing it to report partial results (a response status code that
> indicates not all properties were returned, and/or collection
> members were
> not traversed) for a resource.
>
> IMHO, attempting to synchronize thousands of files with a
> single call to
> the server is not a fantastic idea.
>
> Regards,
>
> Tim
>
>
> Hartmut Warncke <hwarncke@Adobe.COM> on 2000-11-22 04:58:26 PM
>
> Please respond to Hartmut Warncke <hwarncke@Adobe.COM>
>
> To:   "Hall, Shaun" <Shaun.Hall@gbr.xerox.com>, WebDAV WG
>       <w3c-dist-auth@w3.org>
> cc:
> Subject:  Re: [RFC2518 Issue] PROPFIND 'allprop' usage
>
>
>
>
>
>
> > The implications of PROPFIND with an infinite depth affect both the
> server
> > and/or the client. Supposing you have a large WebDAV
> enabled repository.
> The
> > PROPFIND request (a few hundred bytes) could potentially
> mean that (tens
> of)
> > GBs of data is to be returned. Even if the server could
> generate such a
> > large response (which is a feat in its own right), it will load the
> network,
> > and what will happen when the client receives it? Pity the poor user
> sitting
> > there for a long time (hours?), only to be told "timed out"
> or "out of
> > memory" or something similar.
>
> Yes, of course, I completely understand your point of view.
> But as a matter
> of
> fact we like this "depth infinity" feature very much because
> we can use it
> in a
> very efficient way in some situations and therefore we are
> struggleing so
> hard
> for keeping that feature.
>
> > Changing the specification could break existing products,
> which is a bad
> > thing. Backwards compatibilty should be maintained.
>
> Good to hear that. But I am not quite sure how you will do
> that because if
> a
> server has the possibility to refuse a depth infinity request
> GoLive 5 will
> not
> be able to handle that situation (synchronization of client and server
> content
> will not work anymore).
>
> > We think the way forward for the WebDAV specification is to
> allow servers
> > the ability to refuse such requests and inform the client.
> A mechanism
> > should be defined for the client to understand this. If the client
> received
> > a response which basically stated that the server was
> refusing to service
> an
> > infinite depth request, it could issue multiple requests
> with a Depth:1.
>
> If you have to synchronize a very large site with thousands of files,
> replacing
> depth infinity requests by depth 1 requests would be a huge
> performance
> disaster
> for us.
>
> Best, Hartmut
>
>
>
>

------_=_NextPart_001_01C054BF.FF4756A0-- From w3c-dist-auth-request@w3.org Wed Nov 22 15:25:44 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25698 for ; Wed, 22 Nov 2000 15:25:43 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16837; Wed, 22 Nov 2000 15:04:15 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 15:04:15 -0500 (EST) Resent-Message-Id: <200011222004.PAA16837@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA16814 for ; Wed, 22 Nov 2000 15:04:10 -0500 (EST) Received: from d06lmsgate-2.uk.ibm.com (d06lmsgate-2.uk.ibm.com [195.212.29.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28099 for ; Wed, 22 Nov 2000 15:04:10 -0500 From: Tim_Ellison@uk.ibm.com Received: from d06relay01.portsmouth.uk.ibm.com (d06relay01.portsmouth.uk.ibm.com [9.166.84.147]) by d06lmsgate-2.uk.ibm.com (1.0.0) with ESMTP id TAA74478 for ; Wed, 22 Nov 2000 19:50:05 GMT Received: from d06mta07.portsmouth.uk.ibm.com (d06mta08_cs0 [9.180.35.21]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id UAA56204 for ; Wed, 22 Nov 2000 20:03:38 GMT Received: by d06mta07.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8025699F.006E2E71 ; Wed, 22 Nov 2000 20:03:28 +0000 X-Lotus-FromDomain: IBMGB To: w3c-dist-auth@w3.org Message-ID: <8025699F.006E2C33.00@d06mta07.portsmouth.uk.ibm.com> Date: Wed, 22 Nov 2000 20:00:03 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4449 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I have to agree with Shaun that providing an unbounded implementation of 'PROPFIND allprops depth infinity' would be brain dead. Similarly, moving the goal posts to say that allprops no longer returns all the properties would be 'unfavourable' to existing clients and servers. The only tenable position is to allow the server to refuse the request, either in its entirety (no all props and/or no depth infinity) or by allowing it to report partial results (a response status code that indicates not all properties were returned, and/or collection members were not traversed) for a resource. IMHO, attempting to synchronize thousands of files with a single call to the server is not a fantastic idea. Regards, Tim Hartmut Warncke on 2000-11-22 04:58:26 PM Please respond to Hartmut Warncke To: "Hall, Shaun" , WebDAV WG cc: Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > The implications of PROPFIND with an infinite depth affect both the server > and/or the client. Supposing you have a large WebDAV enabled repository. The > PROPFIND request (a few hundred bytes) could potentially mean that (tens of) > GBs of data is to be returned. Even if the server could generate such a > large response (which is a feat in its own right), it will load the network, > and what will happen when the client receives it? Pity the poor user sitting > there for a long time (hours?), only to be told "timed out" or "out of > memory" or something similar. Yes, of course, I completely understand your point of view. But as a matter of fact we like this "depth infinity" feature very much because we can use it in a very efficient way in some situations and therefore we are struggleing so hard for keeping that feature. > Changing the specification could break existing products, which is a bad > thing. Backwards compatibilty should be maintained. Good to hear that. But I am not quite sure how you will do that because if a server has the possibility to refuse a depth infinity request GoLive 5 will not be able to handle that situation (synchronization of client and server content will not work anymore). > We think the way forward for the WebDAV specification is to allow servers > the ability to refuse such requests and inform the client. A mechanism > should be defined for the client to understand this. If the client received > a response which basically stated that the server was refusing to service an > infinite depth request, it could issue multiple requests with a Depth:1. If you have to synchronize a very large site with thousands of files, replacing depth infinity requests by depth 1 requests would be a huge performance disaster for us. Best, Hartmut From w3c-dist-auth-request@w3.org Wed Nov 22 16:05:35 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07287 for ; Wed, 22 Nov 2000 16:05:35 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19060; Wed, 22 Nov 2000 15:55:42 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 15:55:42 -0500 (EST) Resent-Message-Id: <200011222055.PAA19060@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA19037 for ; Wed, 22 Nov 2000 15:55:37 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA00917 for ; Wed, 22 Nov 2000 15:55:38 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.3/8.9.1) with SMTP id MAA18069; Wed, 22 Nov 2000 12:55:33 -0800 (PST) From: "Jim Whitehead" To: "Gino Basso" , Date: Wed, 22 Nov 2000 12:53:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8022A77178C84548B49F5965D38776C805F2E7@wopr.ware2.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: [Moderator Action] Possible error in RFC 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4452 X-Loop: w3c-dist-auth@w3.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 Gino, Thank you for pointing out this problem -- you are right, the specification is in error here. Jason Crawford was the first to point out this problem (http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0247.html), which is noted as issue "NS_BOOBOO" in the RFC 2518 Issues List, at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html - Jim > -----Original Message----- > From: Gino Basso [mailto:GBasso@ware2.com] > Sent: Wednesday, November 22, 2000 12:09 PM > To: 'w3c-dist-auth@w3.org' > Subject: [Moderator Action] Possible error in RFC 2518 > > > Not sure if this is the right discussion list to post this but > I'm wondering > if there is an error in Section 23.4.2. Specifically, shouldn't the second > example read: > > > > rather than > > > > ? > > Gino Basso > Ware2 Software Corp. > > From w3c-dist-auth-request@w3.org Wed Nov 22 16:09:32 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08708 for ; Wed, 22 Nov 2000 16:09:31 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA18826; Wed, 22 Nov 2000 15:50:50 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 15:50:50 -0500 (EST) Resent-Message-Id: <200011222050.PAA18826@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id PAA18806 for ; Wed, 22 Nov 2000 15:50:46 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA00426 for ; Wed, 22 Nov 2000 15:50:46 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.3/8.9.1) with SMTP id MAA17932 for ; Wed, 22 Nov 2000 12:50:44 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 22 Nov 2000 12:49:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: Possible error in RFC 2518 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4451 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Gino Basso to the accept2 list. - Jim -----Original Message----- From: Gino Basso [mailto:GBasso@ware2.com] Sent: Wednesday, November 22, 2000 12:09 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] Possible error in RFC 2518 Not sure if this is the right discussion list to post this but I'm wondering if there is an error in Section 23.4.2. Specifically, shouldn't the second example read: rather than ? Gino Basso Ware2 Software Corp. From w3c-dist-auth-request@w3.org Wed Nov 22 16:34:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15160 for ; Wed, 22 Nov 2000 16:34:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA19905; Wed, 22 Nov 2000 16:20:58 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 16:20:58 -0500 (EST) Resent-Message-Id: <200011222120.QAA19905@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA19884 for ; Wed, 22 Nov 2000 16:20:54 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA03375 for ; Wed, 22 Nov 2000 16:20:53 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.3/8.9.1) with SMTP id NAA19252; Wed, 22 Nov 2000 13:20:52 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Cc: "Eric Sedlar" , "Lisa Dusseault" , "Jim Amsden" Date: Wed, 22 Nov 2000 13:19:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: San Diego IETF: Agenda Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4453 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The WebDAV Working Group will be meeting at the 49th IETF, which is being held in San Diego, CA, December 10-15, 2000. The WebDAV meeting is currently scheduled for Wednesday afternoon, December 13. For details on the San Diego IETF meeting, including location, hotel, and registration information: http://www.ietf.org/meetings/IETF-49.html Lisa Dusseault will be chairing the meeting in my absence (thank you Lisa!). Agenda WebDAV WG meeting Wednesday, December 13, 2000 (3:30-5:30PM) 50min - Open issues and review of the Access Control specification. (Sedlar/Clemm) 30min - Improved HTTP error reporting (Dusseault) 40min - General-purpose WebDAV facilities in the DeltaV protocol (Amsden) The DeltaV working group is also meeting at the San Diego IETF. They are currently scheduled for Thursday, December 14, from 3:30-5:30PM (this is different from the last post I made -- the time has changed). - Jim From w3c-dist-auth-request@w3.org Wed Nov 22 16:48:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18863 for ; Wed, 22 Nov 2000 16:48:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20367; Wed, 22 Nov 2000 16:36:10 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 16:36:10 -0500 (EST) Resent-Message-Id: <200011222136.QAA20367@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA20344 for ; Wed, 22 Nov 2000 16:36:05 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA04623 for ; Wed, 22 Nov 2000 16:35:59 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA20889; Wed, 22 Nov 2000 13:37:21 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Wed, 22 Nov 2000 13:37:21 -0800 From: Greg Stein To: Hartmut Warncke Cc: WebDAV WG Message-ID: <20001122133721.Y21426@lyra.org> Mail-Followup-To: Hartmut Warncke , WebDAV WG References: <3A1BFB32.778D55BF@adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A1BFB32.778D55BF@adobe.com>; from hwarncke@Adobe.COM on Wed, Nov 22, 2000 at 05:58:26PM +0100 X-URL: http://www.lyra.org/greg/ Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4454 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, Nov 22, 2000 at 05:58:26PM +0100, Hartmut Warncke wrote: >... > > We think the way forward for the WebDAV specification is to allow servers > > the ability to refuse such requests and inform the client. A mechanism > > should be defined for the client to understand this. If the client received > > a response which basically stated that the server was refusing to service an > > infinite depth request, it could issue multiple requests with a Depth:1. > > If you have to synchronize a very large site with thousands of files, replacing > depth infinity requests by depth 1 requests would be a huge performance disaster > for us. Given that the default configuration of mod_dav prevents a Depth:infinity PROPFIND, I'd guess that a rejection of Depth:infinity is a definite possibility. What does GoLive do when it gets the rejection? Do you simply skip that feature, send a bunch of Depth:1 requests, or something else? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Nov 22 18:55:41 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22097 for ; Wed, 22 Nov 2000 18:55:40 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23902; Wed, 22 Nov 2000 18:45:36 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 18:45:36 -0500 (EST) Resent-Message-Id: <200011222345.SAA23902@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA23870 for ; Wed, 22 Nov 2000 18:45:31 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA15215 for ; Wed, 22 Nov 2000 18:45:31 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.3/8.9.1) with SMTP id PAA25285 for ; Wed, 22 Nov 2000 15:45:29 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 22 Nov 2000 15:43:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FYI: Protocol security tutorial at San Diego IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4455 X-Loop: w3c-dist-auth@w3.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 http://www.ietf.org/mail-archive/ietf-announce/Current/msg10042.html There will be a Security Tutorital given at the 49th IETF meeting, anyone registered for the IETF meeting is invited to attend. ============================================================== The 1st IETF Security Tutorial: How to Secure a Protocol Date: Sunday, 10 December 2000 Time: 1:00pm - 3:00pm Location: Sheraton San Diego Hotel & Marina, Grand Ballroom A Internet users expect the net to be secure. However without secure protocols it is hard to develop secure systems. Yet what does it mean to produce "secure" protocols? This session will discuss what the problem is, and the several approaches that exist to deal with it. We will discuss existing secure protocols in the RFC suite (TLS, IPSec) with an eye toward the problems that they can solve. We will also discuss when they are not appropriate and what one can do in such a situation. The emphasis will be on practical solutions that can be deployed in protocols today. From w3c-dist-auth-request@w3.org Wed Nov 22 18:57:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22793 for ; Wed, 22 Nov 2000 18:57:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23918; Wed, 22 Nov 2000 18:45:45 -0500 (EST) Resent-Date: Wed, 22 Nov 2000 18:45:45 -0500 (EST) Resent-Message-Id: <200011222345.SAA23918@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA23882 for ; Wed, 22 Nov 2000 18:45:34 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA15218 for ; Wed, 22 Nov 2000 18:45:34 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.3/8.9.1) with SMTP id PAA25288 for ; Wed, 22 Nov 2000 15:45:32 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Wed, 22 Nov 2000 15:43:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FYI: On the use of HTTP as a Substrate to BCP Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4456 X-Loop: w3c-dist-auth@w3.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 potential interest to members of this working group. http://www.ietf.org/mail-archive/ietf-announce/Current/msg09817.html The IESG has received a request to consider On the use of HTTP as a Substrate for Other Protocols as a BCP. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 5, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-moore-using-http-01.txt From w3c-dist-auth-request@w3.org Thu Nov 23 04:53:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09124 for ; Thu, 23 Nov 2000 04:53:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA07164; Thu, 23 Nov 2000 04:38:16 -0500 (EST) Resent-Date: Thu, 23 Nov 2000 04:38:16 -0500 (EST) Resent-Message-Id: <200011230938.EAA07164@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA07144 for ; Thu, 23 Nov 2000 04:38:11 -0500 (EST) Received: from himalia.eastgw.xerox.com (himalia.xerox.com [208.140.33.21]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA19821 for ; Thu, 23 Nov 2000 04:38:10 -0500 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by himalia.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id EAA25708 for ; Thu, 23 Nov 2000 04:38:08 -0500 (EST) Received: from [13.202.65.254] (eurgbrmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA12343 for ; Thu, 23 Nov 2000 09:22:18 GMT Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.0) with ESMTP id for ; Thu, 23 Nov 2000 09:22:53 +0000 Received: by eurgbrbh01.emeacinops.xerox.com with Internet Mail Service (5.5.2651.58) id ; Thu, 23 Nov 2000 09:22:06 -0000 Message-ID: From: "Hall, Shaun" To: w3c-dist-auth@w3.org Date: Thu, 23 Nov 2000 09:22:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4457 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Various responses, see below. > -----Original Message----- > From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com] > Sent: 22 November 2000 20:00 > To: w3c-dist-auth@w3.org > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > I have to agree with Shaun that providing an unbounded > implementation of > 'PROPFIND allprops depth infinity' would be brain dead. > Similarly, moving > the goal posts to say that allprops no longer returns all the > properties > would be 'unfavourable' to existing clients and servers. > > The only tenable position is to allow the server to refuse > the request, > either in its entirety (no all props and/or no depth infinity) or by > allowing it to report partial results (a response status code that > indicates not all properties were returned, and/or collection > members were > not traversed) for a resource. Should we keep the issues of PROPFIND with Depth:Infinity and "allprop" separate threads? > > IMHO, attempting to synchronize thousands of files with a > single call to > the server is not a fantastic idea. We agree, but unfortunately its in the WebDAV spec and products are based on it. We think breaking those products would set WebDAV back a bit. Customers who have paid for products ( sorry Greg :-) ) would not be pleased to find their product incompatible with the lastest WebDAV server. > > Regards, > > Tim > > > Hartmut Warncke on 2000-11-22 04:58:26 PM > > Please respond to Hartmut Warncke > > To: "Hall, Shaun" , WebDAV WG > > cc: > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > [snipped] > > > Changing the specification could break existing products, > which is a bad > > thing. Backwards compatibilty should be maintained. > > Good to hear that. But I am not quite sure how you will do > that because if > a > server has the possibility to refuse a depth infinity request > GoLive 5 will > not > be able to handle that situation (synchronization of client and server > content > will not work anymore). Maintaining backwards compatibility is the challenge for WebDAV spec authors. We need people's ideas/thoughts/etc on how to do this, taking into account the exact behaviour of existing products. For example, use 507 or a new 5xx status code to allow a server to refuse such a request. Would this break existing products? What would they do in such situations? Could vendors of WebDAV clients and even servers (as they could issue these requests for synchronization purposes) state their products behaviour? > > > We think the way forward for the WebDAV specification is to > allow servers > > the ability to refuse such requests and inform the client. > A mechanism > > should be defined for the client to understand this. If the client > received > > a response which basically stated that the server was > refusing to service > an > > infinite depth request, it could issue multiple requests > with a Depth:1. > > If you have to synchronize a very large site with thousands of files, > replacing > depth infinity requests by depth 1 requests would be a huge > performance > disaster > for us. > > Best, Hartmut > Unfortunately its a huge performance disaster on the server as well. What is the point of this behaviour if the server cannot cope under the load? Server implementors might choose one of the following: - server will attempt to perform the request (it may run out of resources and send an error to the client). - server will refuse such a request (which deviates from the RFC, but so be it). Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Thu Nov 23 05:16:08 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17130 for ; Thu, 23 Nov 2000 05:16:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA08225; Thu, 23 Nov 2000 05:05:11 -0500 (EST) Resent-Date: Thu, 23 Nov 2000 05:05:11 -0500 (EST) Resent-Message-Id: <200011231005.FAA08225@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id FAA08160 for ; Thu, 23 Nov 2000 05:04:58 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA21667 for ; Thu, 23 Nov 2000 05:04:41 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id CAA20842; Thu, 23 Nov 2000 02:00:57 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 23 Nov 2000 02:00:57 -0800 From: Greg Stein To: "Hall, Shaun" Cc: w3c-dist-auth@w3.org Message-ID: <20001123020057.Y21426@lyra.org> Mail-Followup-To: "Hall, Shaun" , w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from Shaun.Hall@gbr.xerox.com on Thu, Nov 23, 2000 at 09:22:04AM -0000 X-URL: http://www.lyra.org/greg/ Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4458 X-Loop: w3c-dist-auth@w3.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 Thu, Nov 23, 2000 at 09:22:04AM -0000, Hall, Shaun wrote: >... > > IMHO, attempting to synchronize thousands of files with a > > single call to > > the server is not a fantastic idea. > > We agree, but unfortunately its in the WebDAV spec and products are based on > it. We think breaking those products would set WebDAV back a bit. Customers > who have paid for products ( sorry Greg :-) ) would not be pleased to find > their product incompatible with the lastest WebDAV server. I'm not against paid-for-products. I simply enjoy Open Source development, and have the lucky luxury to be able to work on it full time. Heck. I'd say that *very* few people would be using my code if it weren't for paid-for products. >... > Unfortunately its a huge performance disaster on the server as well. What is > the point of this behaviour if the server cannot cope under the load? Server > implementors might choose one of the following: > - server will attempt to perform the request (it may run out of resources > and send an error to the client). > - server will refuse such a request (which deviates from the RFC, but so be > it). I return a 403 (Forbidden) if a Depth:infinity PROPFIND hits mod_dav and it has not been configured to allow them. Nothing in the RFC about "you MUST NOT return a 403 for a PROPFIND". So I'd dispute your second statement :-) [ and I always have the out: if an admin feels it *does* deviate from the spec, then they can simply enable the thing in their config. they're the ones to live with a DoS attack, not me :-) ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Nov 23 07:19:23 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01930 for ; Thu, 23 Nov 2000 07:19:22 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA11705; Thu, 23 Nov 2000 07:07:39 -0500 (EST) Resent-Date: Thu, 23 Nov 2000 07:07:39 -0500 (EST) Resent-Message-Id: <200011231207.HAA11705@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA11685 for ; Thu, 23 Nov 2000 07:07:35 -0500 (EST) 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 HAA29107 for ; Thu, 23 Nov 2000 07:07:35 -0500 Received: from inner-relay-1.Adobe.COM (inner-relay-1.corp.adobe.com [153.32.1.51]) by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id EAA07951; Thu, 23 Nov 2000 04:10:08 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-1.Adobe.COM (8.8.5) with ESMTP id EAA00252; Thu, 23 Nov 2000 04:05:27 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id NAA09351; Thu, 23 Nov 2000 13:01:52 +0100 (MET) Message-ID: <3A1D0838.90153644@adobe.com> Date: Thu, 23 Nov 2000 13:06:16 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Greg Stein CC: Hartmut Warncke , WebDAV WG References: <3A1BFB32.778D55BF@adobe.com> <20001122133721.Y21426@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4459 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg, > Given that the default configuration of mod_dav prevents a Depth:infinity > PROPFIND, I'd guess that a rejection of Depth:infinity is a definite > possibility. What does GoLive do when it gets the rejection? Do you simply > skip that feature, send a bunch of Depth:1 requests, or something else? We do *not* send a bunch of Depth:1 requests, some WebDAV functionality is simply *not* working in GoLive 5 when the server is not willing to respond to depth infinity requests. We have simply tried to implement the WebDAV protocol as it is described in RFC2518 and RFC2518 does *not* allow a server to deny a depth infinity access. At the point in time when the "DavDepthInfinity" flag was introduced into mod_dav it was much too late for us to implement such a "bunch of Depth:1 requests"-solution because we were right before GM. And I think this is a general problem. There are a lot of very huge products of huge companies out there which support WebDAV and I am very lucky about that especially because I think that the idea of WebDAV is very powerful and advanced. But we all have to keep in mind that a huge product has a well defined life cycle and workflow which cannot be changed frequently. And of course a product cannot be changed when it is already in the box. So when some changes take place in the protocol or its important implementations like mod_dav and this will effect negatively or even break products which are already in the box or right before GM, a customer who have paid for the product has to wait at least for the next product release (which will take months or even years). So I think it's very important to get some degree of stability and continuity in the WebDAV protocol and its implementations which does not mean to let the protocal unchanged during the next years but we should keep its key features. Otherwise a lot of companies will think twice before they implement WebDAV support and - without any doubt - every protocol needs a widespread acceptance from commercial companies and products to be succesful. Best, Hartmut From w3c-dist-auth-request@w3.org Thu Nov 23 07:43:11 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09250 for ; Thu, 23 Nov 2000 07:43:10 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA12491; Thu, 23 Nov 2000 07:26:40 -0500 (EST) Resent-Date: Thu, 23 Nov 2000 07:26:40 -0500 (EST) Resent-Message-Id: <200011231226.HAA12491@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA12470 for ; Thu, 23 Nov 2000 07:26:32 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA30305 for ; Thu, 23 Nov 2000 07:26:31 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id EAA22626; Thu, 23 Nov 2000 04:28:00 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 23 Nov 2000 04:28:00 -0800 From: Greg Stein To: Hartmut Warncke Cc: WebDAV WG Message-ID: <20001123042800.C21426@lyra.org> Mail-Followup-To: Hartmut Warncke , WebDAV WG References: <3A1BFB32.778D55BF@adobe.com> <20001122133721.Y21426@lyra.org> <3A1D0838.90153644@adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A1D0838.90153644@adobe.com>; from hwarncke@Adobe.COM on Thu, Nov 23, 2000 at 01:06:16PM +0100 X-URL: http://www.lyra.org/greg/ Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4461 X-Loop: w3c-dist-auth@w3.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 Thu, Nov 23, 2000 at 01:06:16PM +0100, Hartmut Warncke wrote: > Greg, > > > Given that the default configuration of mod_dav prevents a Depth:infinity > > PROPFIND, I'd guess that a rejection of Depth:infinity is a definite > > possibility. What does GoLive do when it gets the rejection? Do you simply > > skip that feature, send a bunch of Depth:1 requests, or something else? > > We do *not* send a bunch of Depth:1 requests, some WebDAV functionality is simply > *not* working in GoLive 5 when the server is not willing to respond to depth infinity > requests. Eek. You mentioned something about a "sync" feature which uses the Depth:infinity request. Is that it, or are there other times when you use that request type? Is the sync feature used often? Basically, I'm curious about the user impact here. It would be helpful for me if I understood the end-user impact a bit better. [ btw, I just sent mail to Stephanie to see if I can get a copy of GoLive 5 so that I can do some of this interop testing ] > We have simply tried to implement the WebDAV protocol as it is described in > RFC2518 and RFC2518 does *not* allow a server to deny a depth infinity access. At > the point in time when the "DavDepthInfinity" flag was introduced into mod_dav it was > much too late for us to implement such a "bunch of Depth:1 requests"-solution because > we were right before GM. Yes... you beat me up on that one already :-( > And I think this is a general problem. There are a lot of very huge products of huge > companies out there which support WebDAV and I am very lucky about that especially > because I think that the idea of WebDAV is very powerful and advanced. But we all have > to keep in mind that a huge product has a well defined life cycle and workflow which > cannot be changed frequently. And of course a product cannot be changed when it is > already in the box. So when some changes take place in the protocol or its important > implementations like mod_dav and this will effect negatively or even break products > which are already in the box or right before GM, a customer who have paid for the > product has to wait at least for the next product release (which will take months or > even years). I've worked on products with release cycles on the order of two years. Believe me... I understand the issue, and sympathize greatly. On the other hand, I wasn't interested in releasing mod_dav with a known, simple, DoS attack (in the default configuration). Admins can always turn the feature back on, but I'd prefer to see them do it with the understanding of what it means. > So I think it's very important to get some degree of stability and continuity in the > WebDAV protocol and its implementations which does not mean to let the protocal > unchanged during the next years but we should keep its key features. Otherwise a lot > of companies will think twice before they implement WebDAV support and - without any > doubt - every protocol needs a widespread acceptance from commercial companies and > products to be succesful. Agreed. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Nov 23 07:43:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09485 for ; Thu, 23 Nov 2000 07:43:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA12383; Thu, 23 Nov 2000 07:25:13 -0500 (EST) Resent-Date: Thu, 23 Nov 2000 07:25:13 -0500 (EST) Resent-Message-Id: <200011231225.HAA12383@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA12362 for ; Thu, 23 Nov 2000 07:25:06 -0500 (EST) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA30183 for ; Thu, 23 Nov 2000 07:24:25 -0500 Received: from eurodns4.eur.xerox.com (eurodns4.eur.xerox.com [13.202.66.50]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id MAA17483 for ; Thu, 23 Nov 2000 12:23:55 GMT Received: from [13.202.65.253] (eurgbrmg01.eur.xerox.com [13.202.65.253]) by eurodns4.eur.xerox.com (8.9.3/8.9.3) with ESMTP id MAA01700 for ; Thu, 23 Nov 2000 12:08:43 GMT Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.0) with ESMTP id for ; Thu, 23 Nov 2000 12:04:15 +0000 Received: by eurgbrbh01.emeacinops.xerox.com with Internet Mail Service (5.5.2651.58) id ; Thu, 23 Nov 2000 12:03:36 -0000 Message-ID: From: "Hall, Shaun" To: "'W3C WebDAV Mailing List'" Date: Thu, 23 Nov 2000 12:03:35 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: RFC2518 LOCK Response Code Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4460 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: An issue regarding a LOCK response code in RFC2518. A quick search in the archives didn't show anything about this. In section 8.10.4, it states "If the lock cannot be granted to all resources, a 409 (Conflict) status code MUST be returned with a response entity body containing a multi-status XML element...". 1) The 409 status code is not listed in section 8.10.7 (LOCK status codes). 2) The example in section 8.10.10 (Multi-resource LOCK request which fails) returns a 207 (Multi-status) response code, not a 409. The 207 response is normal for WebDAV methods that need to provide information about multiple-resources. I'm inclined to think the 207 is the correct response in such a failure case, which at first implies the 409 is wrong. However, I think the only case where a 409 is applicable is if one it trying to "create" a Lock Null Resource (LNR) (i.e. the null-resource does not exist) and where the ancestors of the LNR do not exist. I think this would be consistent with other methods as well (e.g. PUT, COPY, MOVE). Comments/clarification/etc please. Regards Shaun Hall Xerox Europe From w3c-dist-auth-request@w3.org Thu Nov 23 09:35:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05889 for ; Thu, 23 Nov 2000 09:35:54 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA15875; Thu, 23 Nov 2000 09:14:45 -0500 (EST) Resent-Date: Thu, 23 Nov 2000 09:14:45 -0500 (EST) Resent-Message-Id: <200011231414.JAA15875@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA15852 for ; Thu, 23 Nov 2000 09:14:40 -0500 (EST) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA06196 for ; Thu, 23 Nov 2000 09:14:41 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id GAA09528; Thu, 23 Nov 2000 06:16:55 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id GAA01963; Thu, 23 Nov 2000 06:13:23 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id PAA15501; Thu, 23 Nov 2000 15:09:01 +0100 (MET) Message-ID: <3A1D2607.ACC553B0@adobe.com> Date: Thu, 23 Nov 2000 15:13:27 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Greg Stein , WebDAV WG References: <3A1BFB32.778D55BF@adobe.com> <20001122133721.Y21426@lyra.org> <3A1D0838.90153644@adobe.com> <20001123042800.C21426@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4462 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg, > > We do *not* send a bunch of Depth:1 requests, some WebDAV functionality is simply > > *not* working in GoLive 5 when the server is not willing to respond to depth infinity > > requests. > > Eek. You mentioned something about a "sync" feature which uses the > Depth:infinity request. Is that it, or are there other times when you use > that request type? Is the sync feature used often? Yes, it is mainly the sync feature which uses this request but it's a very important and often used feature. With synchronizing a file "a.html" I mean to perform a PROPFIND request on "a.html" in order to figure out if it has been changed after the last time you have downloaded that file to your local machine. Synchronizing a huge folder means to check this out for the folder and all its content. So if the user wants to synchronize a folder with a lot of resources in it it is very efficient to do that with one PROPFIND-infinity request. > I've worked on products with release cycles on the order of two years. > Believe me... I understand the issue, and sympathize greatly. Yes, I know and believe that! > On the other hand, I wasn't interested in releasing mod_dav with a known, > simple, DoS attack (in the default configuration). Admins can always turn > the feature back on, but I'd prefer to see them do it with the understanding > of what it means. Yes, I know and understand your point of view but, as I already pointed out, we like those requests because they are pretty efficient for us and we are very sensitive to changes of the protocol or its most important implementations. Best, Hartmut From w3c-dist-auth-request@w3.org Fri Nov 24 04:02:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13220 for ; Fri, 24 Nov 2000 04:02:05 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA07059; Fri, 24 Nov 2000 03:45:11 -0500 (EST) Resent-Date: Fri, 24 Nov 2000 03:45:11 -0500 (EST) Resent-Message-Id: <200011240845.DAA07059@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id DAA07039 for ; Fri, 24 Nov 2000 03:45:06 -0500 (EST) Received: from hermes.eurgw.xerox.com (root@hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA10690 for ; Fri, 24 Nov 2000 03:44:55 -0500 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id IAA14260 for ; Fri, 24 Nov 2000 08:44:19 GMT Received: from [13.202.65.253] (eurgbrmg01.eur.xerox.com [13.202.65.253]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id IAA19717 for ; Fri, 24 Nov 2000 08:03:59 GMT Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.0) with ESMTP id for ; Fri, 24 Nov 2000 08:04:15 +0000 Received: by eurgbrbh01.emeacinops.xerox.com with Internet Mail Service (5.5.2651.58) id ; Fri, 24 Nov 2000 08:03:37 -0000 Message-ID: <117E8D1FCCA3D111940C00805FEF6060016A1871@gbrwgcms01.wgc.gbr.xerox.com> From: "Wright, Tom" To: "'WebDAV WG'" Date: Fri, 24 Nov 2000 08:03:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4463 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Various replies below Regards Tom Wright Xerox All comments are my own opinions and not really from my company. -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] Sent: 23 November 2000 12:06 To: Greg Stein Cc: Hartmut Warncke; WebDAV WG Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Greg, > Given that the default configuration of mod_dav prevents a Depth:infinity > PROPFIND, I'd guess that a rejection of Depth:infinity is a definite > possibility. What does GoLive do when it gets the rejection? Do you simply > skip that feature, send a bunch of Depth:1 requests, or something else? >We do *not* send a bunch of Depth:1 requests, some WebDAV functionality is simply >*not* working in GoLive 5 when the server is not willing to respond to depth infinity >requests. We have simply tried to implement the WebDAV protocol as it is described in >RFC2518 and RFC2518 does *not* allow a server to deny a depth infinity access. At >the point in time when the "DavDepthInfinity" flag was introduced into mod_dav it was >much too late for us to implement such a "bunch of Depth:1 requests"-solution because >we were right before GM. >And I think this is a general problem. There are a lot of very huge products of huge >companies out there which support WebDAV and I am very lucky about that especially >because I think that the idea of WebDAV is very powerful and advanced. But we all have >to keep in mind that a huge product has a well defined life cycle and workflow which >cannot be changed frequently. And of course a product cannot be changed when it is >already in the box. So when some changes take place in the protocol or its important >implementations like mod_dav and this will effect negatively or even break products >which are already in the box or right before GM, a customer who have paid for the >product has to wait at least for the next product release (which will take months or e>ven years). Though Issuing patches is a well known tried an trusted appropach to this kind of problem. >So I think it's very important to get some degree of stability and continuity in the >WebDAV protocol and its implementations which does not mean to let the protocal >unchanged during the next years but we should keep its key features. Otherwise a lot >of companies will think twice before they implement WebDAV support and - without any >doubt - every protocol needs a widespread acceptance from commercial companies and >products to be succesful. All of your responses are missing the point Hartmut. If a server generates a 2 or 4 Gigabyte XML response in response to your thousands of files on the server, 1) its going to hog the server, and even cause it to fail if your building XML in memory, 2) clog the network with traffic and 3) how on earth is the client going to cope with parsing a 2 or 4 gig ( or larger ) XML response, are you simply hoping that you never get a response so large that you cant handle it ? Sending a few hundred byte request ( which may be reasonable to the user ) can result in potentially crippling the server, network or client with unexpectedly large amounts of data, after all most users have no idea of the size of the response before hand. I agree we need to do our best to maintain backwards compatability, but it sounds like your check all in one go approach is a naive implementation. There is simply no need to retrieve more than a directory ( ala depth 1 ) of files/folders properties at a time. Heck you dont even need webdav to do this, using if-modified-since is good enough for files, unless you need to check properties as well. Your arguement about it being efficient is hard to understand. Whats efficent, your use of server and client resources, network band width etc ? I am actually implementing propfind as we speak, and have full sympathy with your position and agree we must not break backwards compatibility, however the current spec is 1) a draft and 2) not considerate of resources, after all they are not infinite. I am suprised greg has not argued the case of infinite depth and got the spec changed!! Maybe the best compromise is as shaun suggested is to have a new status code, saying i have done a depth 1 instead of a depth infinity propfind response, the rest is up to you kind of code, some new 200 code perhaps. The current situation of allowing infinite depth allprop with an unknown number of properties for an unknown number of resources is 'silly'. The protocol is not just for clients, servers have to implement it also, and they need to be able to throatle malicious/unintentional requests which will potentially flood the network and cripple the server/client. As a whole, i hope Jim is reading these emails, as there is clearly a number of people unhappy with the current specification. Maybe it should be changed before the next release? Best regards Tom From w3c-dist-auth-request@w3.org Sat Nov 25 08:51:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13822 for ; Sat, 25 Nov 2000 08:51:24 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA02504; Sat, 25 Nov 2000 08:41:41 -0500 (EST) Resent-Date: Sat, 25 Nov 2000 08:41:41 -0500 (EST) Resent-Message-Id: <200011251341.IAA02504@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA02481 for ; Sat, 25 Nov 2000 08:41:37 -0500 (EST) Received: from sioux.hosts.netdirect.net.uk (root@sioux.hosts.netdirect.net.uk [195.7.224.43]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA21347 for ; Sat, 25 Nov 2000 08:41:36 -0500 Received: from ojzxmxqo (th-pm08-28.ndirect.co.uk [195.7.237.28]) by sioux.hosts.netdirect.net.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA30415; Sat, 25 Nov 2000 13:41:18 GMT Message-ID: <004f01c056e6$3809b140$0200000a@ojzxmxqo> From: "csamson" To: "WebDAV WG" , "Jim Whitehead" Date: Sat, 25 Nov 2000 13:46:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Subject: Re: Looking for Java WebDav clients..response Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4464 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit A few months ago, I was looking for examples of simple Java client code for accessing a WebDAV server. There are relatively few examples of any HTTP Java client code available on the internet, let alone WebDAV ! I put the following test program together (thanks also to the WebDAV list for a few pieces of advice). Rather than the overhead of a full XML parser, I wrote a simple routine to extract the elements I wanted from the returned responses. The example tests GET, PROPFIND, LOCK, PUT and UNLOCK, shows how to implement Basic Authentication and how to handle locktokens. As IE does not have a Java Console, I write messages out to the screen once each example has been called. No apologies for the code - it's messy but it worked for testing purposes ! It works over the Internet with Sharemation, but not mydocsonline as this does not seem to support the Lock command. To test this out on Sharemation, which supports WebDAV a) create a user account. b)add a file such as rfc2518.htm c) run from within your Java environment (or create an applet) with the following parameter properties set.... where username and password are the sharemation account username and password. The Java source can be downloaded from www.screenplan.com/webdav.html I'd welcome comments - please post any feedback to the working group, if appropriate, or mail me separately. Regards, JC Samson -----Original Message----- From: Jim Whitehead To: WebDAV WG Date: 22 November 2000 04:06 Subject: FW: Looking for Java WebDav clients.. >Accidentally caught by the spam filter. I've added Anselm Rajendra to the >accept2 list. > >- Jim > >-----Original Message----- >From: Anslem Rajendra [mailto:AnslemR@truespectra.com] >Sent: Tuesday, November 21, 2000 2:43 PM >To: 'w3c-dist-auth@w3.org' >Subject: [Moderator Action] Looking for Java WebDav clients.. > > >Hello, > >My company is investigating the possiblity of creating an asset management >soln using webDav. I was looking for any Java webDav clients with source >code that may be helpful in this endevour. Would you know if there are any >out there. Also, would there be any libraries within Sun's java libraries >to support this in the future. > >Thanks, >Anslem. > From w3c-dist-auth-request@w3.org Sun Nov 26 12:51:22 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15440 for ; Sun, 26 Nov 2000 12:51:21 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA18477; Sun, 26 Nov 2000 12:39:20 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 12:39:20 -0500 (EST) Resent-Message-Id: <200011261739.MAA18477@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id MAA18457 for ; Sun, 26 Nov 2000 12:39:15 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA03551 for ; Sun, 26 Nov 2000 12:39:15 -0500 Received: from canuck (c204.ppp.tsoft.com [198.144.204.204]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id JAA17683; Sun, 26 Nov 2000 09:38:55 -0800 (PST) From: "Lisa Dusseault" To: "Hartmut Warncke" Cc: "WebDAV WG" Date: Sun, 26 Nov 2000 09:41:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A1BC630.32C1974D@adobe.com> Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4465 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm still a little confused -- Does GoLive do PROPFIND depth-infinity 'allprop' requests? Nobody's talking about removing (or cutting back) support for PROPFIND depth-infinity requests for _specific_ (named in request) properties, just for 'allprop'. Lisa > -----Original Message----- > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > Sent: Wednesday, November 22, 2000 5:12 AM > To: Lisa Dusseault > Cc: WebDAV WG > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > Lisa, > > > > One more question, because maybe, as Richard Humphreys suggests, "depth > > infinity" is the problem. > > > > Hartmut, does GoLive5 use depth: infinity PROPFIND requests at > all? If yes, > > does it use them for custom property discovery? > > Yes, GoLive uses those infinity requests because it's a very > effiicient way to > synchronize the WebDAV server content with the content of a site > on the local > machine with *o n e* network request. We are requesting build-in DAV > properties (like "getlastmodified" or "lockdiscovery") as well as custom > properties (which were PROPPATCHED by GoLive before) with depth infinity. > > To my mind depth infinity requests are -from the client > perspective - a very > efficient and interesting WebDAV feature. > Dropping infinite requests would break GoLive 5! > > By the way if a server would be allowed to refuse depth infinity > requests (like > mod_dav with its "DavDepthInfinity" flag in its configuration > file), the client > needs a mechanism to figure out if the server is willing to > respond to depth > infinity requests or not. This mechanism has to be precisely > defined by RFC2518. > > > > > If not, then we could compromise our way through this by stating that a > > WebDAV server SHOULD (MUST?) respond to a PROPFIND depth-0 > 'allprop' request > > with all custom properties, but that it MAY respond to a > PROPFIND depth>0 > > 'allprop' request with a more limited set of properties > (suggested to be the > > non-locking-related properties defined in RFC2518 presently). > > > > Would that work? > > I think "allprop" should always return all properties (custom and > DAV build-in). > Perhaps it makes sense to drop PROPFIND-ALLPROP requests with > depth infinity but > please keep the PROPFIND-PROP requests with depth infinity > because they are a > very powerful and efficient instrument. Dropping those requests > would lead us > -in some situations- into a time consuming disaster with a huge amount of > network traffic. > > Best, Hartmut > > > > > -----Original Message----- > > > From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] > > > Sent: Monday, November 13, 2000 8:07 AM > > > To: Lisa Dusseault > > > Cc: WebDAV WG > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > > > > > To clarify, does the GoLive 5 WebDAV client rely on using > > > PROPFIND 'allprop' > > > > requests to get all custom properties on **any** webDAV server? > > > or against > > > > a specific webDAV server? > > > > > > On **any** WebDAV server. > > > > > > > Have you tested this against various servers? > > > > Does it work with all of them? > > > > > > Yes, it's working against IIS and mod_dav for example. > > > > > > Best, Hartmut > > > > > > > > > > > -----Original Message----- > > > > > From: w3c-dist-auth-request@w3.org > > > > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Hartmut Warncke > > > > > Sent: Monday, November 13, 2000 4:07 AM > > > > > To: Lisa Dusseault; WebDAV WG > > > > > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I have major concerns regarding the change of the response > > > on a PROPFIND > > > > > 'allprop' request in the way you described it. > > > > > > > > > > Such a change would be *v e r y harmful* for the GoLive 5 > > > > > WebDAV client. > > > > > When we send a PROPFIND 'allprop' request we expect all > > > > > properties which are > > > > > defined on the resource, especially the Lockproperties > and all custom > > > > > properties defined by GoLive 5 (which we have PROPPATCHED before). > > > > > > > > > > We are probably able to replace PROPFIND 'allprop' requests by > > > > > PROPFIND 'prop' > > > > > requests in future GoLive releases (which would be indeed much > > > > > more efficient) > > > > > but the suggested change in the protocol would be a *disaster* > > > > > for GoLive 5 > > > > > which is already in the box. > > > > > > > > > > Best, Hartmut > > > > > > > > > > > > > > > Lisa Dusseault wrote: > > > > > > > > > > > Past discussions have shown that servers frequently have trouble > > > > > > implementing PROPFIND 'allprop'. Jim asked me to > summarize the past > > > > > > discussion & list the open issues so that we can get this > > > > > fixed, if it can > > > > > > be fixed, in revisions to 2518. > > > > > > > > > > > > There are already cases where not all properties will > be returned: > > > > > > RFC2518: "In the case of allprop and propname, if a principal > > > > > does not have > > > > > > the > > > > > > right to know whether a particular property exists then > > > the property > > > > > > should be silently excluded from the response." > > > > > > > > > > > > John Stracke's proposal for reducing/specifying the scope of > > > > > 'allprop', and > > > > > > discussion of the motivation: > > > > > > - > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0092.html > > > > > > - > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0310.html > > > > > > > > > > > > It has been a point of discussion for Advanced Collections: > > > > > > - > > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0008.html > > > > > > "Clients need to know whether the property is computed on > > > the fly before > > > > > > requesting it. There is no way to find out. The impact of > > > > > computing on the > > > > > > fly is especially significant when a client requests allprop. > > > > > There may be > > > > > > other properties that are computed on the fly as well. > > > DAV:getetag is > > > > > > computed, and some versioning history properties may also > > > be computed." > > > > > > > > > > > > Also in Versioning: > > > > > > - > > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0075.html > > > > > "There has also been a massive growth in the number of > available DAV > > > > > properties. PROPFIND allprop operations may lead to very large > > > > > responses even with Depth: 1, which would slow down performance > > > > > for users due to network speeds. It might be worthwhile > to add this > > > > > facet to the open issue ALLPROP_AND_COMPUTED." > > > > > > > > > > Also in ACLs, Babich argues that clients who request > 'allprop' don't > > > > really > > > > > want to see the ACL property, thus they ought to specifically > > > ask for it. > > > > > - > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0101.html > > > > > > > > Several server implementors have voiced the opinion that 'allprop' > > should > > > be > > > > "put out of its misery" (GMC) or at least weakened. Often this is > > because > > > > of standard or custom properties that must be calculated by > the server > > > (e.g. > > > > 'lockdiscovery'), and the calculation can become extraordinarily > > expensive > > > > with an 'allprop' of depth: infinity. > > > > > > > > The only server-side argument for keeping 'allprop' is that > > > server-to-server > > > > COPY requires it; but if anybody has implemented this yet > and can't use > > > > 'propname' instead, please speak up. > > > > > > > > Summary: > > > > There thus seems to be a consensus among server > implementors and those > > > > designing new features for DAV. What's missing in order to > resolve this > > > > issue for fixing RFC2518 is input from clients. > > > > > > > > 1. Is anybody aware of clients that rely on particular > properties being > > > > returned in 'allprop'? If the properties relied upon > include any more > > > than > > > > the set DAV:{creationdate, displayname, getcontentlanguage, > > > > getcontentlength, getcontenttype, getetag, getlastmodified} (the > > > properties > > > > required for DAV level 1 support) I would be very surprised. Thus, > > > servers > > > > may be able to restrict the required property set to this set. > > > > > > > > 2. Is anybody aware of clients that rely on 'allprop', rather than > > > > 'propname', for property discovery? This would be a more > serious issue > > if > > > > major client implementations actually rely on doing > property discovery > > > using > > > > 'allprop', and attempt this against various implementations > of WebDAV > > > > servers. > > > > > > > > These seem to be our options for modifying RFC2518 > (remember, it has to > > be > > > a > > > > simple mod): > > > > - deprecate 'allprop' and tell clients not to use it, but to use > > > 'propname' > > > > instead > > > > - define 'allprop' to be the set of properties required > for DAV level 1 > > > > support (although servers could freely return more properties if > > desired) > > > > - explicitly allow servers to return an error code (507?) for > > properties > > > > that were too expensive to calculate for a 'allprop' > request, but still > > > > allowing the client to do property discovery through 'allprop' > > > > > > > > Please voice your preferences among these options, > objections, or other > > > > ideas. > > > > > > > > thanks, > > > > Lisa > > > > Xythos > From w3c-dist-auth-request@w3.org Sun Nov 26 18:11:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20191 for ; Sun, 26 Nov 2000 18:11:29 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22538; Sun, 26 Nov 2000 18:02:59 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 18:02:59 -0500 (EST) Resent-Message-Id: <200011262302.SAA22538@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA22518 for ; Sun, 26 Nov 2000 18:02:56 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA23957 for ; Sun, 26 Nov 2000 18:02:55 -0500 Received: from lyta ([216.102.212.250]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0G4N00K6RMKPB7@mta6.snfc21.pbi.net> for w3c-dist-auth@w3.org; Sun, 26 Nov 2000 15:00:26 -0800 (PST) Date: Sun, 26 Nov 2000 15:02:33 -0800 From: Kevin Wiggen In-reply-to: <117E8D1FCCA3D111940C00805FEF6060016A1871@gbrwgcms01.wgc.gbr.xerox.com> To: "Wright, Tom" , "'WebDAV WG'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Priority: 3 (Normal) Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4467 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit 2) Allprop. I have not seen any answers for WHY people want to use Allprop, except for there are clients that use it today. This is why I would like to Deprecate the use of Allprop. Yes servers will continue to support it for backward compatibility, but I believe that NEW clients should NEVER use ALLPROP. If a client NEEDS all the properties (and not just the properties it knows how to handle), it can do a PROPNAME followed by a PROPFIND asking for all the properties. Thus the corner case of needing all the properties is still available, but is not the generic case. I also would like to remove ALLPROP as the default for PROPFIND. I have seen the number of things people are using Properties for. Its both genius and scary :) But I can see no reason why a client would care about most of them unless they specifically knew what they meant. In which case they know to ask for them. I think the spec should change to disallow ALLPROP from clients. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Wright, Tom Sent: Friday, November 24, 2000 12:04 AM To: 'WebDAV WG' Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Various replies below Regards Tom Wright Xerox All comments are my own opinions and not really from my company. -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] Sent: 23 November 2000 12:06 To: Greg Stein Cc: Hartmut Warncke; WebDAV WG Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Greg, > Given that the default configuration of mod_dav prevents a Depth:infinity > PROPFIND, I'd guess that a rejection of Depth:infinity is a definite > possibility. What does GoLive do when it gets the rejection? Do you simply > skip that feature, send a bunch of Depth:1 requests, or something else? >We do *not* send a bunch of Depth:1 requests, some WebDAV functionality is simply >*not* working in GoLive 5 when the server is not willing to respond to depth infinity >requests. We have simply tried to implement the WebDAV protocol as it is described in >RFC2518 and RFC2518 does *not* allow a server to deny a depth infinity access. At >the point in time when the "DavDepthInfinity" flag was introduced into mod_dav it was >much too late for us to implement such a "bunch of Depth:1 requests"-solution because >we were right before GM. >And I think this is a general problem. There are a lot of very huge products of huge >companies out there which support WebDAV and I am very lucky about that especially >because I think that the idea of WebDAV is very powerful and advanced. But we all have >to keep in mind that a huge product has a well defined life cycle and workflow which >cannot be changed frequently. And of course a product cannot be changed when it is >already in the box. So when some changes take place in the protocol or its important >implementations like mod_dav and this will effect negatively or even break products >which are already in the box or right before GM, a customer who have paid for the >product has to wait at least for the next product release (which will take months or e>ven years). Though Issuing patches is a well known tried an trusted appropach to this kind of problem. >So I think it's very important to get some degree of stability and continuity in the >WebDAV protocol and its implementations which does not mean to let the protocal >unchanged during the next years but we should keep its key features. Otherwise a lot >of companies will think twice before they implement WebDAV support and - without any >doubt - every protocol needs a widespread acceptance from commercial companies and >products to be succesful. All of your responses are missing the point Hartmut. If a server generates a 2 or 4 Gigabyte XML response in response to your thousands of files on the server, 1) its going to hog the server, and even cause it to fail if your building XML in memory, 2) clog the network with traffic and 3) how on earth is the client going to cope with parsing a 2 or 4 gig ( or larger ) XML response, are you simply hoping that you never get a response so large that you cant handle it ? Sending a few hundred byte request ( which may be reasonable to the user ) can result in potentially crippling the server, network or client with unexpectedly large amounts of data, after all most users have no idea of the size of the response before hand. I agree we need to do our best to maintain backwards compatability, but it sounds like your check all in one go approach is a naive implementation. There is simply no need to retrieve more than a directory ( ala depth 1 ) of files/folders properties at a time. Heck you dont even need webdav to do this, using if-modified-since is good enough for files, unless you need to check properties as well. Your arguement about it being efficient is hard to understand. Whats efficent, your use of server and client resources, network band width etc ? I am actually implementing propfind as we speak, and have full sympathy with your position and agree we must not break backwards compatibility, however the current spec is 1) a draft and 2) not considerate of resources, after all they are not infinite. I am suprised greg has not argued the case of infinite depth and got the spec changed!! Maybe the best compromise is as shaun suggested is to have a new status code, saying i have done a depth 1 instead of a depth infinity propfind response, the rest is up to you kind of code, some new 200 code perhaps. The current situation of allowing infinite depth allprop with an unknown number of properties for an unknown number of resources is 'silly'. The protocol is not just for clients, servers have to implement it also, and they need to be able to throatle malicious/unintentional requests which will potentially flood the network and cripple the server/client. As a whole, i hope Jim is reading these emails, as there is clearly a number of people unhappy with the current specification. Maybe it should be changed before the next release? Best regards Tom From w3c-dist-auth-request@w3.org Sun Nov 26 18:12:17 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20370 for ; Sun, 26 Nov 2000 18:12:13 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22434; Sun, 26 Nov 2000 18:01:28 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 18:01:28 -0500 (EST) Resent-Message-Id: <200011262301.SAA22434@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA22411 for ; Sun, 26 Nov 2000 18:01:23 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA23838 for ; Sun, 26 Nov 2000 18:01:24 -0500 Received: from lyta ([216.102.212.250]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0G4N00IH0MFAUA@mta6.snfc21.pbi.net> for w3c-dist-auth@w3.org; Sun, 26 Nov 2000 14:57:11 -0800 (PST) Date: Sun, 26 Nov 2000 14:59:17 -0800 From: Kevin Wiggen In-reply-to: <117E8D1FCCA3D111940C00805FEF6060016A1871@gbrwgcms01.wgc.gbr.xerox.com> To: "Wright, Tom" , "'WebDAV WG'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Priority: 3 (Normal) Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4466 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think this should be split into 2 threads (as someone suggested earlier) and so I will attempt to do so here :) 1) Depth infinity searches. I can see some very good uses for depth infinity searches and can also see the large DOS attack. To alleviate the situation I will suggest (again) that we add a 507 Insufficient Storage status code response to a Propfind. This will allow a server to respond with partial results when the result set is to large. This was how DASL suggested that servers handle the Result Set Truncation possibility of searches that were to large, and since Propfind is nothing but a limited search, I believe the 507 works well in this case also. In this way the server is free to answer as much as they can, and still give a proper error condition. In cases where the depth infinity is not rather large, the 207 is returned as normal. In the case of LARGE depth infinity propfinds, the 507 is returned with partial propfind data. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Wright, Tom Sent: Friday, November 24, 2000 12:04 AM To: 'WebDAV WG' Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Various replies below Regards Tom Wright Xerox All comments are my own opinions and not really from my company. -----Original Message----- From: Hartmut Warncke [mailto:hwarncke@Adobe.COM] Sent: 23 November 2000 12:06 To: Greg Stein Cc: Hartmut Warncke; WebDAV WG Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Greg, > Given that the default configuration of mod_dav prevents a Depth:infinity > PROPFIND, I'd guess that a rejection of Depth:infinity is a definite > possibility. What does GoLive do when it gets the rejection? Do you simply > skip that feature, send a bunch of Depth:1 requests, or something else? >We do *not* send a bunch of Depth:1 requests, some WebDAV functionality is simply >*not* working in GoLive 5 when the server is not willing to respond to depth infinity >requests. We have simply tried to implement the WebDAV protocol as it is described in >RFC2518 and RFC2518 does *not* allow a server to deny a depth infinity access. At >the point in time when the "DavDepthInfinity" flag was introduced into mod_dav it was >much too late for us to implement such a "bunch of Depth:1 requests"-solution because >we were right before GM. >And I think this is a general problem. There are a lot of very huge products of huge >companies out there which support WebDAV and I am very lucky about that especially >because I think that the idea of WebDAV is very powerful and advanced. But we all have >to keep in mind that a huge product has a well defined life cycle and workflow which >cannot be changed frequently. And of course a product cannot be changed when it is >already in the box. So when some changes take place in the protocol or its important >implementations like mod_dav and this will effect negatively or even break products >which are already in the box or right before GM, a customer who have paid for the >product has to wait at least for the next product release (which will take months or e>ven years). Though Issuing patches is a well known tried an trusted appropach to this kind of problem. >So I think it's very important to get some degree of stability and continuity in the >WebDAV protocol and its implementations which does not mean to let the protocal >unchanged during the next years but we should keep its key features. Otherwise a lot >of companies will think twice before they implement WebDAV support and - without any >doubt - every protocol needs a widespread acceptance from commercial companies and >products to be succesful. All of your responses are missing the point Hartmut. If a server generates a 2 or 4 Gigabyte XML response in response to your thousands of files on the server, 1) its going to hog the server, and even cause it to fail if your building XML in memory, 2) clog the network with traffic and 3) how on earth is the client going to cope with parsing a 2 or 4 gig ( or larger ) XML response, are you simply hoping that you never get a response so large that you cant handle it ? Sending a few hundred byte request ( which may be reasonable to the user ) can result in potentially crippling the server, network or client with unexpectedly large amounts of data, after all most users have no idea of the size of the response before hand. I agree we need to do our best to maintain backwards compatability, but it sounds like your check all in one go approach is a naive implementation. There is simply no need to retrieve more than a directory ( ala depth 1 ) of files/folders properties at a time. Heck you dont even need webdav to do this, using if-modified-since is good enough for files, unless you need to check properties as well. Your arguement about it being efficient is hard to understand. Whats efficent, your use of server and client resources, network band width etc ? I am actually implementing propfind as we speak, and have full sympathy with your position and agree we must not break backwards compatibility, however the current spec is 1) a draft and 2) not considerate of resources, after all they are not infinite. I am suprised greg has not argued the case of infinite depth and got the spec changed!! Maybe the best compromise is as shaun suggested is to have a new status code, saying i have done a depth 1 instead of a depth infinity propfind response, the rest is up to you kind of code, some new 200 code perhaps. The current situation of allowing infinite depth allprop with an unknown number of properties for an unknown number of resources is 'silly'. The protocol is not just for clients, servers have to implement it also, and they need to be able to throatle malicious/unintentional requests which will potentially flood the network and cripple the server/client. As a whole, i hope Jim is reading these emails, as there is clearly a number of people unhappy with the current specification. Maybe it should be changed before the next release? Best regards Tom From w3c-dist-auth-request@w3.org Sun Nov 26 20:46:59 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27325 for ; Sun, 26 Nov 2000 20:46:58 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA24071; Sun, 26 Nov 2000 20:35:31 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 20:35:31 -0500 (EST) Resent-Message-Id: <200011270135.UAA24071@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA24047 for ; Sun, 26 Nov 2000 20:35:25 -0500 (EST) Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA01093 for ; Sun, 26 Nov 2000 20:35:25 -0500 Received: from 204.167.8.157 (tantalum.atria.com) by gw.atria.com id Sun, 26 Nov 2000 20:35:24 -0500 (EST) Received: (from gclemm@localhost) by tantalum.atria.com (8.8.8+Sun/8.8.8) id UAA00004; Sun, 26 Nov 2000 20:34:45 -0500 (EST) Date: Sun, 26 Nov 2000 20:34:45 -0500 (EST) Message-Id: <200011270134.UAA00004@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-reply-to: (message from Kevin Wiggen on Sun, 26 Nov 2000 15:02:33 -0800) References: Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4468 X-Loop: w3c-dist-auth@w3.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 heartily support the removal of allprop from the protocol. If client writers start now to replace their use of allprop-PROPFIND with a propname-PROPFIND/PROPFIND pair, they have plenty of time to be in compliance with a revision of 2518 that does not support allprop. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Nov 26 21:01:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01703 for ; Sun, 26 Nov 2000 21:01:49 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA24366; Sun, 26 Nov 2000 20:47:44 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 20:47:44 -0500 (EST) Resent-Message-Id: <200011270147.UAA24366@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA24346 for ; Sun, 26 Nov 2000 20:47:41 -0500 (EST) Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA01864 for ; Sun, 26 Nov 2000 20:47:41 -0500 Received: from 204.167.8.157 (tantalum.atria.com) by gw.atria.com id Sun, 26 Nov 2000 20:47:40 -0500 (EST) Received: (from gclemm@localhost) by tantalum.atria.com (8.8.8+Sun/8.8.8) id UAA00023; Sun, 26 Nov 2000 20:47:00 -0500 (EST) Date: Sun, 26 Nov 2000 20:47:00 -0500 (EST) Message-Id: <200011270147.UAA00023@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-reply-to: (message from Kevin Wiggen on Sun, 26 Nov 2000 14:59:17 -0800) References: Subject: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND 'allprop' usage) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4469 X-Loop: w3c-dist-auth@w3.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 support the use of 507 to indicate a server wishes to truncate the PROPFIND. I assume that if a server will respond with partial results, that the 507 will be returned under the appropriate response elements (whose properties were omitted), while the overall status of the request would be a 207. Cheers, Geoff Date: Sun, 26 Nov 2000 14:59:17 -0800 From: Kevin Wiggen I think this should be split into 2 threads (as someone suggested earlier) and so I will attempt to do so here :) 1) Depth infinity searches. I can see some very good uses for depth infinity searches and can also see the large DOS attack. To alleviate the situation I will suggest (again) that we add a 507 Insufficient Storage status code response to a Propfind. This will allow a server to respond with partial results when the result set is to large. This was how DASL suggested that servers handle the Result Set Truncation possibility of searches that were to large, and since Propfind is nothing but a limited search, I believe the 507 works well in this case also. In this way the server is free to answer as much as they can, and still give a proper error condition. In cases where the depth infinity is not rather large, the 207 is returned as normal. In the case of LARGE depth infinity propfinds, the 507 is returned with partial propfind data. Kevin From w3c-dist-auth-request@w3.org Sun Nov 26 21:21:02 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05920 for ; Sun, 26 Nov 2000 21:20:59 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA24940; Sun, 26 Nov 2000 21:08:14 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 21:08:14 -0500 (EST) Resent-Message-Id: <200011270208.VAA24940@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA24920 for ; Sun, 26 Nov 2000 21:08:07 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA03202 for ; Sun, 26 Nov 2000 21:08:05 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA13347 for w3c-dist-auth@w3.org; Sun, 26 Nov 2000 18:09:57 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sun, 26 Nov 2000 18:09:57 -0800 From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: <20001126180957.O21426@lyra.org> Mail-Followup-To: w3c-dist-auth@w3.org References: <200011270134.UAA00004@tantalum.atria.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200011270134.UAA00004@tantalum.atria.com>; from geoffrey.clemm@rational.com on Sun, Nov 26, 2000 at 08:34:45PM -0500 X-URL: http://www.lyra.org/greg/ Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4470 X-Loop: w3c-dist-auth@w3.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 Sun, Nov 26, 2000 at 08:34:45PM -0500, Geoffrey M. Clemm wrote: > > I heartily support the removal of allprop from the protocol. > > If client writers start now to replace their use of allprop-PROPFIND > with a propname-PROPFIND/PROPFIND pair, they have plenty of time > to be in compliance with a revision of 2518 that does not support > allprop. I vehemently agree. :-) I also support limitations on Depth:infinity requests (as if you couldn't guess :-). [ mod_dav (by default) just tosses them, responding with 403 (Forbidden); since that is a legal return for a PROPFIND, it seemed to make sense in my situation (and clients would have to deal with it anyways). ] Returning 507 would be a bit more difficult implementation-wise. However, I think we really shouldn't allow that mechanism. What is a client to do when it gets a 507? How does it know *what* was left out, and *how* to get those results? Did the server do a depth-first or a breadth-first response of properties? Which collections did it recurse into and which did it not? Did it stop *partway* through a collection? How can a client tell? With all of those problems, a client has to be *extremely* smart to recover. It would have to sort through the returned hrefs, analyze the structure, and try to determine where the server left off. Pathological case: let's say that I implemented the server with a database mapping URLs to property sets. I have a spiffy query that returns all rows that start with a particular URL base. For performance purposes, I *do* not sort the response, and the database does not guarantee one. Oh oh... what now? I've got responses in a scatter plot all over the URL namespace. One alternative would be for the server to "prune" responses and mark these prunings in the response. The client could then know exactly what is missing (" resource" or " collection"). This mechanism would also be nice for a "propname" or a "prop" style of PROPFIND with Depth:infinity. I could easily see a server wanting to prune those, too. Personally, I say put the 507 and specifically allow 403 responses. [ I wouldn't mind if Depth:infinity was tossed altogether, but that is too extreme, and that depth is *very* handy for debugging :-) ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Nov 26 21:26:38 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07158 for ; Sun, 26 Nov 2000 21:26:38 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA24991; Sun, 26 Nov 2000 21:10:03 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 21:10:03 -0500 (EST) Resent-Message-Id: <200011270210.VAA24991@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA24969 for ; Sun, 26 Nov 2000 21:09:59 -0500 (EST) Received: from kurgan.lyra.org (kurgan.lyra.org [198.144.203.198]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA03270 for ; Sun, 26 Nov 2000 21:09:58 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id SAA13356 for w3c-dist-auth@w3.org; Sun, 26 Nov 2000 18:11:47 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Sun, 26 Nov 2000 18:11:47 -0800 From: Greg Stein To: "'WebDAV WG'" Message-ID: <20001126181147.P21426@lyra.org> Mail-Followup-To: 'WebDAV WG' References: <117E8D1FCCA3D111940C00805FEF6060016A1871@gbrwgcms01.wgc.gbr.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from wiggs@wiggenout.com on Sun, Nov 26, 2000 at 03:02:33PM -0800 X-URL: http://www.lyra.org/greg/ Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4471 X-Loop: w3c-dist-auth@w3.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 Sun, Nov 26, 2000 at 03:02:33PM -0800, Kevin Wiggen wrote: >... > I also would like to remove ALLPROP as the default for PROPFIND. We either have to toss the default, or leave it. We can't really change the default to something else (the only valid one would be 'propname'). I'm fine with returning 400 (Bad Request) for a PROPFIND with no body. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Nov 26 22:32:34 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23818 for ; Sun, 26 Nov 2000 22:32:34 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA25595; Sun, 26 Nov 2000 22:22:58 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 22:22:58 -0500 (EST) Resent-Message-Id: <200011270322.WAA25595@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA25572 for ; Sun, 26 Nov 2000 22:22:53 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by tux.w3.org (8.9.3/8.9.3) with SMTP id WAA07602 for ; Sun, 26 Nov 2000 22:22:53 -0500 Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 26 Nov 2000 19:22:19 -0800 (Pacific Standard Time) Received: by inet-imc-02.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Sun, 26 Nov 2000 19:22:14 -0800 Message-ID: <1E27BBCDDE50914C99517B4D7EC5D5251EBC00@RED-MSG-13.redmond.corp.microsoft.com> From: Terry Crowley To: "'Greg Stein'" , w3c-dist-auth@w3.org Date: Sun, 26 Nov 2000 19:22:07 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4472 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'd have to agree on the point that a 507 response isn't particularly useful. Just what is a client supposed to do with that? How are they supposed to recover? What kind of feedback do they provide to the user that they just got back a partial result set (and as Greg points out, it would be very difficult to know how it was truncated). Many clients would want to just treat that as a complete failure and try a different approach, but in the meantime they might have had to download and parse a very large (but not large enough) response that they end up discarding. Terry Crowley >> Returning 507 would be a bit more difficult implementation-wise. However, I >> think we really shouldn't allow that mechanism. What is a client to do when >> it gets a 507? How does it know *what* was left out, and *how* to get those >> results? Did the server do a depth-first or a breadth-first response of >> properties? Which collections did it recurse into and which did it not? Did >> it stop *partway* through a collection? How can a client tell? >> -- >> Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun Nov 26 23:00:58 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29687 for ; Sun, 26 Nov 2000 23:00:56 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA26061; Sun, 26 Nov 2000 22:51:39 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 22:51:39 -0500 (EST) Resent-Message-Id: <200011270351.WAA26061@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id WAA26040 for ; Sun, 26 Nov 2000 22:51:34 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA09514 for ; Sun, 26 Nov 2000 22:51:35 -0500 Received: from canuck (c204.ppp.tsoft.com [198.144.204.204]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id TAA20819; Sun, 26 Nov 2000 19:51:16 -0800 (PST) From: "Lisa Dusseault" To: "Greg Stein" , Date: Sun, 26 Nov 2000 19:53:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20001126180957.O21426@lyra.org> Subject: RE: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4473 X-Loop: w3c-dist-auth@w3.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 agree with the desire for the client to find out *what's* missing, and the 207 multistatus allows a server to fill in a "507" response for each property that it chooses to omit due to processing or space limitations. E.g. a depth-0 'allprop' response could still legitimately omit the value of the ACL property but mark its presence with the 507 status code. However, I'm not sure it's so easy for a server to indicate that it has omitted a whole hierarchy in a 207 multistatus response. What if the client asks for depth-infinity 'allprop' on a directory with sub-directories? I guess the server could: - for every item in the directory that is not a sub-directory, respond normally with property values or property status codes - for sub-directories that it wishes not to recurse into, include this kind of XML /subdir HTTP/1.1 507 Insufficient Storage This appears legal under RFC 2518's definition of the elements that can/must go in the response element. I don't see any way for the server to return the properties for 'subdir' while simultaneously indicating to the client that it did not recurse into 'subdir'. Thus in order to limit its answer, the server would omit the property set for 'subdir' as well. Not the best of solutions; anybody have brighter ideas? Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Sunday, November 26, 2000 6:10 PM > To: w3c-dist-auth@w3.org > Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage > > > On Sun, Nov 26, 2000 at 08:34:45PM -0500, Geoffrey M. Clemm wrote: > > > > I heartily support the removal of allprop from the protocol. > > > > If client writers start now to replace their use of allprop-PROPFIND > > with a propname-PROPFIND/PROPFIND pair, they have plenty of time > > to be in compliance with a revision of 2518 that does not support > > allprop. > > I vehemently agree. :-) > > > I also support limitations on Depth:infinity requests (as if you couldn't > guess :-). > > [ mod_dav (by default) just tosses them, responding with 403 (Forbidden); > since that is a legal return for a PROPFIND, it seemed to make > sense in my > situation (and clients would have to deal with it anyways). ] > > Returning 507 would be a bit more difficult implementation-wise. > However, I > think we really shouldn't allow that mechanism. What is a client > to do when > it gets a 507? How does it know *what* was left out, and *how* to > get those > results? Did the server do a depth-first or a breadth-first response of > properties? Which collections did it recurse into and which did > it not? Did > it stop *partway* through a collection? How can a client tell? > > With all of those problems, a client has to be *extremely* smart > to recover. > It would have to sort through the returned hrefs, analyze the > structure, and > try to determine where the server left off. > > Pathological case: let's say that I implemented the server with a database > mapping URLs to property sets. I have a spiffy query that returns all rows > that start with a particular URL base. For performance purposes, > I *do* not > sort the response, and the database does not guarantee one. Oh oh... what > now? I've got responses in a scatter plot all over the URL namespace. > > One alternative would be for the server to "prune" responses and > mark these > prunings in the response. The client could then know exactly what > is missing > (" resource" or " collection"). This mechanism would also be > nice for a "propname" or a "prop" style of PROPFIND with Depth:infinity. I > could easily see a server wanting to prune those, too. > > Personally, I say put the 507 and specifically allow 403 responses. > > [ I wouldn't mind if Depth:infinity was tossed altogether, but that is too > extreme, and that depth is *very* handy for debugging :-) ] > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Mon Nov 27 00:12:08 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13641 for ; Mon, 27 Nov 2000 00:12:06 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA27164; Sun, 26 Nov 2000 23:59:41 -0500 (EST) Resent-Date: Sun, 26 Nov 2000 23:59:41 -0500 (EST) Resent-Message-Id: <200011270459.XAA27164@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id XAA27139 for ; Sun, 26 Nov 2000 23:59:36 -0500 (EST) Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA14039 for ; Sun, 26 Nov 2000 23:59:36 -0500 Received: from 204.167.8.157 (tantalum.atria.com) by gw.atria.com id Sun, 26 Nov 2000 23:59:34 -0500 (EST) Received: (from gclemm@localhost) by tantalum.atria.com (8.8.8+Sun/8.8.8) id XAA00225; Sun, 26 Nov 2000 23:58:55 -0500 (EST) Date: Sun, 26 Nov 2000 23:58:55 -0500 (EST) Message-Id: <200011270458.XAA00225@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-reply-to: <20001126180957.O21426@lyra.org> (message from Greg Stein on Sun, 26 Nov 2000 18:09:57 -0800) References: <200011270134.UAA00004@tantalum.atria.com> <20001126180957.O21426@lyra.org> Subject: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND 'allprop' usage) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4474 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Note that the 507 proposal is not for dealing with allprop, but rather with dealing with depth infinity, so I've modified the subject line (Kevin valiantly tried to separate the issues, but they seem to keep getting mashed back together :-). From: Greg Stein Returning 507 would be a bit more difficult implementation-wise. However, I think we really shouldn't allow that mechanism. What is a client to do when it gets a 507? If it gets a 507 as the top level status, it knows it has to retry the request with a smaller depth. If it gets a 207 as the top level status, and a 507 as the status of some member, it has to retry the request on that member directly. How does it know *what* was left out, It knows by what results are 507's and what are 200's. Note: the proposal is not that you use a 507 to omit some of the properties in a response element, but rather to omit *all* of the requested properties in the response element. and *how* to get those results? See above. Did the server do a depth-first or a breadth-first response of properties? I assume you mean, a depth-first or breadth-first search of the members? If so, you would be able to tell by what response elements are 200's and what are 507's. Which collections did it recurse into and which did it not? Did it stop *partway* through a collection? How can a client tell? We would need to define server behavior here. For example: "you have to return the properties of a collection if you are going to return properties of any of its members, and you return 507 if you are not going to return properties of the collection or any of its members, due to space limitations". With all of those problems, a client has to be *extremely* smart to recover. It would have to sort through the returned hrefs, analyze the structure, and try to determine where the server left off. If we define it properly, it only has to retry the 507's. Pathological case: let's say that I implemented the server with a database mapping URLs to property sets. I have a spiffy query that returns all rows that start with a particular URL base. For performance purposes, I *do* not sort the response, and the database does not guarantee one. Oh oh... what now? I've got responses in a scatter plot all over the URL namespace. Just prune out all the responses whose URL match certain prefixes, and return a 507 for the collections that you pruned out. One alternative would be for the server to "prune" responses and mark these prunings in the response. The client could then know exactly what is missing (" resource" or " collection"). Yes. (What don't you like about this alternative?) This mechanism would also be nice for a "propname" or a "prop" style of PROPFIND with Depth:infinity. I could easily see a server wanting to prune those, too. I'm not quite sure what you are referring to here. The 507's are for pruning responses when the depth is too great, and is independent of whether it is a propname or prop style PROPFIND. Personally, I say punt the 507 and specifically allow 403 responses. The 403 would definitely leave the client in the dark ... it wouldn't know whether or not to retry the PROPFIND with a different depth. Whereas the 507 tells the client very clearly that it is the depth value that is too great, while still giving it some of what it asked for. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 27 00:17:16 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14699 for ; Mon, 27 Nov 2000 00:17:15 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA27414; Mon, 27 Nov 2000 00:04:21 -0500 (EST) Resent-Date: Mon, 27 Nov 2000 00:04:21 -0500 (EST) Resent-Message-Id: <200011270504.AAA27414@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id AAA27394 for ; Mon, 27 Nov 2000 00:04:17 -0500 (EST) Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA14385 for ; Mon, 27 Nov 2000 00:04:18 -0500 Received: from 204.167.8.157 (tantalum.atria.com) by gw.atria.com id Mon, 27 Nov 2000 00:04:17 -0500 (EST) Received: (from gclemm@localhost) by tantalum.atria.com (8.8.8+Sun/8.8.8) id AAA00242; Mon, 27 Nov 2000 00:03:37 -0500 (EST) Date: Mon, 27 Nov 2000 00:03:37 -0500 (EST) Message-Id: <200011270503.AAA00242@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-reply-to: References: Subject: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND 'allprop' usage) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4475 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: "Lisa Dusseault" I don't see any way for the server to return the properties for 'subdir' while simultaneously indicating to the client that it did not recurse into 'subdir'. Thus in order to limit its answer, the server would omit the property set for 'subdir' as well. Not the best of solutions; anybody have brighter ideas? If the server wants to return properties for subdir, but not for its children, it would just return a 507 for each of its children. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Nov 27 01:56:03 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14165 for ; Mon, 27 Nov 2000 01:56:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA28493; Mon, 27 Nov 2000 01:46:10 -0500 (EST) Resent-Date: Mon, 27 Nov 2000 01:46:10 -0500 (EST) Resent-Message-Id: <200011270646.BAA28493@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id BAA28473 for ; Mon, 27 Nov 2000 01:46:05 -0500 (EST) Received: from shell.tsoft.com (root@shell.tsoft.com [198.144.192.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA22214 for ; Mon, 27 Nov 2000 01:46:06 -0500 Received: from canuck (c204.ppp.tsoft.com [198.144.204.204]) by shell.tsoft.com (8.8.7/8.8.7) with SMTP id WAA16017; Sun, 26 Nov 2000 22:46:02 -0800 (PST) From: "Lisa Dusseault" To: "Geoffrey M. Clemm" , Date: Sun, 26 Nov 2000 22:48:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <200011270458.XAA00225@tantalum.atria.com> Subject: RE: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND 'allprop' usage) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4476 X-Loop: w3c-dist-auth@w3.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 agree with everything except... > -----Original Message----- > From: Geoffrey M. Clemm > To: w3c-dist-auth@w3.org > Subject: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND > 'allprop' usage) > > Note: the > proposal is not that you use a 507 to omit some of the properties in a > response element, but rather to omit *all* of the requested properties > in the response element. I disagree about the scope of the proposal, at least the proposal that _I'd_ like to make. I know this isn't exactly the same issue, but servers want to (anthropomorphically-speaking) be able to omit property values which are too expensive to compute when the PROPFIND covers many resources. Thus, with a PROPFIND request covering a number of resources simultaneously, the server could choose to include the 507 response rather than the property value. This is even easier than omitting sub-directories, because 2518 already has examples of returning an error for a specific property (p 25-26 shows two properties omitted due to permissions). It's because these two issues, expensive properties and depth-infinity PROPFIND, are so similar that we've been unable to separate them in mail threads. Luckily I think they can be dealt with in a very similar manner. I'd like it to be explained, in RFC2518 ideally or at least understood through the mailing list, that a client must be prepared to get incomplete PROPFIND results containing 507 codes in status elements to indicate that it was too expensive to calculate certain properties or to recurse into certain trees. With this much information, the client is perfectly able to send more specific requests to fill in the holes, whether they be missing property-values or missing resource-details. This ought not to be too uncomfortable a change for existing clients: since this is legal within 2518, it should not absolutely break them. And, there is nothing forcing servers to return incomplete results, so any server implementor can choose to remain compatible with existing clients relying on depth-infinity PROPFIND returning complete results. Lisa From w3c-dist-auth-request@w3.org Mon Nov 27 04:39:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24627 for ; Mon, 27 Nov 2000 04:39:51 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA00054; Mon, 27 Nov 2000 04:25:58 -0500 (EST) Resent-Date: Mon, 27 Nov 2000 04:25:58 -0500 (EST) Resent-Message-Id: <200011270925.EAA00054@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA00004 for ; Mon, 27 Nov 2000 04:25:53 -0500 (EST) Received: from hermes.eurgw.xerox.com (hermes.ext.eurgw.xerox.com [212.120.143.5]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA00606 for ; Mon, 27 Nov 2000 04:25:39 -0500 Received: from eurodns2.eur.xerox.com (eurodns2.eur.xerox.com [13.202.66.10]) by hermes.eurgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA13163 for ; Mon, 27 Nov 2000 09:24:59 GMT Received: from [13.202.65.254] (eurgbrmg02.eur.xerox.com [13.202.65.254]) by eurodns2.eur.xerox.com (8.9.3/8.9.3) with ESMTP id JAA01238 for ; Mon, 27 Nov 2000 09:19:31 GMT Received: from eurgbrbh01.emeacinops.xerox.com (unverified) by (Content Technologies SMTPRS 4.2.0) with ESMTP id for ; Mon, 27 Nov 2000 09:20:05 +0000 Received: by eurgbrbh01.emeacinops.xerox.com with Internet Mail Service (5.5.2651.58) id ; Mon, 27 Nov 2000 09:19:26 -0000 Message-ID: From: "Hall, Shaun" To: "'W3C WebDAV Mailing List'" Date: Mon, 27 Nov 2000 09:19:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND 'allpr op' usage) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4477 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Wow, which message should I reply to ? :-). This seemed to be the most appropriate. Regards Shaun Hall Xerox Europe > -----Original Message----- > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > Sent: 27 November 2000 04:59 > To: w3c-dist-auth@w3.org > Subject: Depth infinity PROPFIND (was: [RFC2518 Issue] PROPFIND > 'allprop' usage) > > > > Note that the 507 proposal is not for dealing with allprop, > but rather with dealing with depth infinity, so I've modified > the subject line (Kevin valiantly tried to separate the issues, > but they seem to keep getting mashed back together :-). I originally suggested that we should keep the "depth:infinity" and "allprop" separate and the EXAMPLE use of 507. I asked for people's ideas/comments/etc. 507 as stated in my previous email, was just an example. You guys are beating it to death which is a good thing for writing specs. > > From: Greg Stein > > Returning 507 would be a bit more difficult > implementation-wise. However, I think we really shouldn't allow > that mechanism. What is a client to do when it gets a 507? > > If it gets a 507 as the top level status, it knows it has to retry > the request with a smaller depth. If it gets a 207 as the top level > status, and a 507 as the status of some member, it has to retry the > request on that member directly. > > How does > it know *what* was left out, > > It knows by what results are 507's and what are 200's. Note: the > proposal is not that you use a 507 to omit some of the properties in a > response element, but rather to omit *all* of the requested properties > in the response element. > > and *how* to get those results? When I meant 507, I did not mean for it to be in the XML part of the response, but the actual HTTP response code e.g.: HTTP/1.1 507 Insufficent Storage Content-Type: xyz ... With such a code, no XML needs to be returned, no "partial response" is given, "some properties are omitted" etc. In other words, everything is omitted, so the client doesn't have to parse a "largish" response etc (as people have mentioned). This way, the client doesn't have to be too clever in to figure out what parts/properties/resources/etc the server omitted. It simply knows the whole response for the request was too large. Being a little bit smart though, it could then issue PROPFIND requests that would not generate such large responses (i.e Depth:1). This use of 507 may deviate though from RFC2518. I do think that "pruning" the response (i.e. 507 XML in a 207 response) is a bad idea and would be rather difficult for the client to handle. [snipped] > > > Personally, I say punt the 507 and specifically allow 403 > responses. > > The 403 would definitely leave the client in the dark ... it wouldn't > know whether or not to retry the PROPFIND with a different depth. > Whereas the 507 tells the client very clearly that it is the depth > value that is too great, while still giving it some of what it asked > for. > > Cheers, > Geoff > As I orginally asked, can people suggest ideas of how to handle PROPFIND with a Depth:Infinity request, whilst trying to maintain backwards compatibility with existing clients. In other words, if people are unhappy with my suggested use of 507, suggest something else. From w3c-dist-auth-request@w3.org Mon Nov 27 05:12:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05075 for ; Mon, 27 Nov 2000 05:12:04 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA00402; Mon, 27 Nov 2000 04:57:19 -0500 (EST) Resent-Date: Mon, 27 Nov 2000 04:57:19 -0500 (EST) Resent-Message-Id: <200011270957.EAA00402@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id EAA00378 for ; Mon, 27 Nov 2000 04:57:14 -0500 (EST) Received: from smtp-relay-2.Adobe.COM (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA02463 for ; Mon, 27 Nov 2000 04:57:14 -0500 Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52]) by smtp-relay-2.Adobe.COM (8.8.6) with ESMTP id BAA17914; Mon, 27 Nov 2000 01:59:09 -0800 (PST) Received: from mail-hamburg.eur.Adobe.COM by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id BAA02478; Mon, 27 Nov 2000 01:55:36 -0800 (PST) Received: by mail-hamburg.eur.Adobe.COM (8.7.5) with ESMTP id KAA14001; Mon, 27 Nov 2000 10:51:12 +0100 (MET) Message-ID: <3A222F9B.B9969BF8@adobe.com> Date: Mon, 27 Nov 2000 10:55:39 +0100 From: Hartmut Warncke X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Lisa Dusseault , WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [RFC2518 Issue] PROPFIND 'allprop' usage Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4478 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, > I'm still a little confused -- Does GoLive do PROPFIND depth-infinity > 'allprop' requests? No, we only use PROPFIND-PROP requests for specific properties with depth infinity. > Nobody's talking about removing (or cutting back) support for PROPFIND > depth-infinity requests for _specific_ (named in request) properties, just > for 'allprop'. I am not quite sure if this is the opinion of all members on this list. I think a lot of people want to cut off depth infinity at all. Best, Hartmut From w3c-dist-auth-request@w3.org Mon Nov 27 08:22:04 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05892 for ; Mon, 27 Nov 2000 08:22:03 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA02698; Mon, 27 Nov 2000 08:12:00 -0500 (EST) Resent-Date: Mon, 27 Nov 2000 08:12:00 -0500 (EST) Resent-Message-Id: <200011271312.IAA02698@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id IAA02678 for ; Mon, 27 Nov 2000 08:11:56 -0500 (EST) Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA15503 for ; Mon, 27 Nov 2000 08:11:52 -0500 Received: from 204.167.8.157 (tantalum.atria.com) by gw.atria.com id Mon, 27 Nov 2000 08:11:48 -0500 (EST) Received: (from gclemm@localhost) by tantalum.atria.com (8.8.8+Sun/8.8.8) id IAA00818; Mon, 27 Nov 2000 08:11:09 -0500 (EST) Date: Mon, 27 Nov 2000 08:11:09 -0500 (EST) Message-Id: <200011271311.IAA00818@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-reply-to: (Shaun.Hall@gbr.xerox.com) References: Subject: Re: Depth infinity PROPFIND Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4479 X-Loop: w3c-dist-auth@w3.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: "Hall, Shaun" When I meant 507, I did not mean for it to be in the XML part of the response, but the actual HTTP response code e.g.: HTTP/1.1 507 Insufficent Storage Content-Type: xyz ... With such a code, no XML needs to be returned, no "partial response" is given, "some properties are omitted" etc. In other words, everything is omitted, so the client doesn't have to parse a "largish" response etc (as people have mentioned). Yes, a top level 507 response is appropriate, and tells the server that the request needs to be re-issued with a smaller Depth value. But a nested 507 response inside of a 207 is also appropriate when the server is willing to process a limited amount of what the client asked for. This way, the client doesn't have to be too clever in to figure out what parts/properties/resources/etc the server omitted. It simply knows the whole response for the request was too large. Being a little bit smart though, it could then issue PROPFIND requests that would not generate such large responses (i.e Depth:1). The use of nested 507's inside of a 207 This saves the client the guesswork of what is a "reasonable" Depth value. Depth:1 can always be used, but it might generate significantly fewer requests if you let the server pick the depth. This use of 507 may deviate though from RFC2518. Any use of 507 in this way deviates from the spec (it is not defined as being a response from a PROPFIND), but it is a "benign" deviation, since although it may surprise existing clients, it doesn't "change" the meaning of a 507 from a PROPFIND (since there was no prior meaning). I do think that "pruning" the response (i.e. 507 XML in a 207 response) is a bad idea and would be rather difficult for the client to handle. Because ... ? It was ready to parse the XML, and needed to handle errors in the nested results, so the only additional thing it needs to do is to issue another PROPFIND whenever it encounters a 507 (assuming it wants to do so ... it might not if it wasn't expecting a deep/wide tree). As I orginally asked, can people suggest ideas of how to handle PROPFIND with a Depth:Infinity request, whilst trying to maintain backwards compatibility with existing clients. In other words, if people are unhappy with my suggested use of 507, suggest something else. The only argument against 507 has been "it's hard for clients" ... but I don't yet see how it is hard. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Nov 28 09:38:09 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29794 for ; Tue, 28 Nov 2000 09:38:09 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA09086; Tue, 28 Nov 2000 09:31:02 -0500 (EST) Resent-Date: Tue, 28 Nov 2000 09:31:02 -0500 (EST) Resent-Message-Id: <200011281431.JAA09086@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA09066 for ; Tue, 28 Nov 2000 09:30:58 -0500 (EST) Received: from smail2.dmz1.icn.siemens.it ([194.185.160.243]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA11129 for ; Tue, 28 Nov 2000 09:30:56 -0500 Received: FROM imail.icn.siemens.it BY smail2.dmz1.icn.siemens.it ; Tue Nov 28 15:29:49 2000 +0100 Received: from ilt9h01.settimo.italtel.it (ilt9h01.settimo.italtel.it [138.132.3.41]) by imail.icn.siemens.it (8.9.3/8.9.3) with SMTP id PAA22460; Tue, 28 Nov 2000 15:28:08 +0100 (MET) Received: from [138.132.49.75] by ilt9h01.settimo.italtel.it with SMTP (1.38.193.5/16.2) id AA19053; Tue, 28 Nov 2000 15:13:15 +0100 Message-Id: <3A23C125.EDAE9D81@icn.siemens.it> Date: Tue, 28 Nov 2000 15:28:53 +0100 From: Simone Pensa Organization: Siemens Information and Communication Networks SpA X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: Mailing list DELTAV , Mailing list WEBDAV Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Differences Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4480 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm just reading the documnentation of both groups ... I didn't understand what is the difference of the two working groups. Someone could tell me something ... Can I consider deltav as the continuation of webdav ? If so, why webdav is still working ? Thanks Simone Pensa From w3c-dist-auth-request@w3.org Tue Nov 28 13:42:08 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03188 for ; Tue, 28 Nov 2000 13:42:07 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA24369; Tue, 28 Nov 2000 13:30:02 -0500 (EST) Resent-Date: Tue, 28 Nov 2000 13:30:02 -0500 (EST) Resent-Message-Id: <200011281830.NAA24369@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA24347 for ; Tue, 28 Nov 2000 13:29:58 -0500 (EST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10979 for ; Tue, 28 Nov 2000 13:29:58 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA17090 for ; Tue, 28 Nov 2000 13:03:15 -0600 Received: from d04nm303.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id NAA43588 for ; Tue, 28 Nov 2000 13:29:22 -0500 To: Simone Pensa Cc: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Jim Amsden" Date: Tue, 28 Nov 2000 13:20:15 -0500 X-MIMETrack: Serialize by Router on D04NM303/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 11/28/2000 01:29:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Differences Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4481 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Simone, The IETF area directors don't like to see a working group go on forever. They prefer to see it specify a charter, execute on the charter, publish standards, and disband. This keeps the work fresh, encourages completion of deliverables, and allows new working groups to be created with new members. The DeltaV working group is a new working group whose charter is to provide versioning extensions to WebDAV. If this work was done in the WebDAV working group, it would take a lot longer to get RFC2518 done which would result in fewer WebDAV implementations. By separating these concerns, we encourage development of WebDAV servers which are useful now, and get a new set of working group members who are more experienced in versioning and document management systems. So you can consider DeltaV as a continuation of WebDAV for versioning and configuration management extensions. However, the WebDAV working group is still active as RFC2518 is not yet an Internet Standard. I'm just reading the documnentation of both groups ... I didn't understand what is the difference of the two working groups. Someone could tell me something ... Can I consider deltav as the continuation of webdav ? If so, why webdav is still working ? Thanks Simone Pensa From w3c-dist-auth-request@w3.org Tue Nov 28 18:40:01 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16908 for ; Tue, 28 Nov 2000 18:40:00 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA05227; Tue, 28 Nov 2000 18:27:52 -0500 (EST) Resent-Date: Tue, 28 Nov 2000 18:27:52 -0500 (EST) Resent-Message-Id: <200011282327.SAA05227@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA05193 for ; Tue, 28 Nov 2000 18:27:47 -0500 (EST) Received: from services.cse.ucsc.edu (services.cse.ucsc.edu [128.114.48.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA12028 for ; Tue, 28 Nov 2000 18:27:47 -0500 Received: from galileo (dhcp-63-142.cse.ucsc.edu [128.114.63.142]) by services.cse.ucsc.edu (8.9.3/8.9.1) with SMTP id PAA17701 for ; Tue, 28 Nov 2000 15:27:41 -0800 (PST) From: "Jim Whitehead" To: "WebDAV WG" Date: Tue, 28 Nov 2000 15:25:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: Differences Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4482 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I've added Angsuman to the accept2 list, so future posts from him will be accepted. - Jim -----Original Message----- From: Angsuman Chakraborty [mailto:angsuman@doubletwist.com] Sent: Tuesday, November 28, 2000 10:21 AM To: 'Simone Pensa'; Mailing list DELTAV; Mailing list WEBDAV Subject: [Moderator Action] RE: Differences deltav is responsible for adding full(?) versioning capabilities to webdav. A client implementation of Source Code Management system can be easily built to work with webdav server with deltav extensions, something not possible with just webdav impl. Hope that helps, Angsuman -----Original Message----- From: Simone Pensa [mailto:simone.pensa@icn.siemens.it] Sent: Tuesday, November 28, 2000 6:29 AM To: Mailing list DELTAV; Mailing list WEBDAV Subject: Differences I'm just reading the documnentation of both groups ... I didn't understand what is the difference of the two working groups. Someone could tell me something ... Can I consider deltav as the continuation of webdav ? If so, why webdav is still working ? Thanks Simone Pensa From w3c-dist-auth-request@w3.org Wed Nov 29 02:51:50 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23246 for ; Wed, 29 Nov 2000 02:51:48 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA15505; Wed, 29 Nov 2000 02:36:39 -0500 (EST) Resent-Date: Wed, 29 Nov 2000 02:36:39 -0500 (EST) Resent-Message-Id: <200011290736.CAA15505@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id CAA15485 for ; Wed, 29 Nov 2000 02:36:34 -0500 (EST) Received: from mr14.vic-remote.bigpond.net.au (mr14.vic-remote.bigpond.net.au [24.192.1.29]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA10810 for ; Wed, 29 Nov 2000 02:36:30 -0500 Received: from bigpond.net.au (CPE-144-132-12-73.vic.bigpond.net.au [144.132.12.73]) by mr14.vic-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id SAA10736 for ; Wed, 29 Nov 2000 18:35:54 +1100 (EDT) Message-ID: <3A24A349.BA8F105D@bigpond.net.au> Date: Wed, 29 Nov 2000 17:33:45 +1100 From: Jason Harrop X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FW: Looking for Java WebDav clients.. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4483 X-Loop: w3c-dist-auth@w3.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 Anslem, You might also like to try the WebDav client part of the Slide project http://jakarta.apache.org/slide/ To inspect the WebDav client straight away, look at it in CVS (thanks Greg Stein!): http://jakarta.apache.org/cvsweb/index.cgi/jakarta-slide/src/webdav/client/src/org/apache/webdav/ You can of course also download a pre-built jar file. cheers, Jason > > -----Original Message----- > From: Anslem Rajendra [mailto:AnslemR@truespectra.com] > Sent: Tuesday, November 21, 2000 2:43 PM > To: 'w3c-dist-auth@w3.org' > Subject: [Moderator Action] Looking for Java WebDav clients.. > > Hello, > > My company is investigating the possiblity of creating an asset management > soln using webDav. I was looking for any Java webDav clients with source > code that may be helpful in this endevour. Would you know if there are any > out there. Also, would there be any libraries within Sun's java libraries > to support this in the future. > > Thanks, > Anslem. From w3c-dist-auth-request@w3.org Thu Nov 30 16:20:53 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21401 for ; Thu, 30 Nov 2000 16:20:53 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA03532; Thu, 30 Nov 2000 16:05:01 -0500 (EST) Resent-Date: Thu, 30 Nov 2000 16:05:01 -0500 (EST) Resent-Message-Id: <200011302105.QAA03532@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA03503 for ; Thu, 30 Nov 2000 16:04:55 -0500 (EST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA20036 for ; Thu, 30 Nov 2000 16:04:56 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 30 Nov 2000 14:04:20 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 30 Nov 2000 14:04:12 -0700 From: "Som Bandyopadhyay" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id QAA03503 Subject: Webdav servers over internet Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4484 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, There used to be a list of webdav servers over internet kept some where ( along with their capabilities listed )...can someone point me to that list ? I don't seem to find the list any more ( only referenece I find is sharemation and riverfront's mention in www.webdav.org )...but their used to be a larger list. thanks, som. +------------------------------------------------------------ | Name: Somenath Bandyopadhyay | Title: Senior Software Engineer | Contact Information: ph: 801-861-3093 | Novell, Inc., the leading provider of Net services software | www.novell.com |'Chess holds its master in its own bonds, shackling | the mind and brain so that the inner freedom of the |very strongest must suffer' - Albert Einstein +------------------------------------------------------------ From w3c-dist-auth-request@w3.org Thu Nov 30 17:19:04 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16110 for ; Thu, 30 Nov 2000 17:19:02 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA05721; Thu, 30 Nov 2000 16:55:21 -0500 (EST) Resent-Date: Thu, 30 Nov 2000 16:55:21 -0500 (EST) Resent-Message-Id: <200011302155.QAA05721@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA05697 for ; Thu, 30 Nov 2000 16:55:14 -0500 (EST) Received: from kurgan.lyra.org (test.webdav.org [198.144.203.199]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA25837 for ; Thu, 30 Nov 2000 16:55:13 -0500 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id NAA07740; Thu, 30 Nov 2000 13:57:38 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Thu, 30 Nov 2000 13:57:38 -0800 From: Greg Stein To: Som Bandyopadhyay Cc: w3c-dist-auth@w3.org Message-ID: <20001130135737.Q25840@lyra.org> Mail-Followup-To: Som Bandyopadhyay , w3c-dist-auth@w3.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from SBANDYO@novell.com on Thu, Nov 30, 2000 at 02:04:12PM -0700 X-URL: http://www.lyra.org/greg/ Subject: Re: Webdav servers over internet Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4485 X-Loop: w3c-dist-auth@w3.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 Thu, Nov 30, 2000 at 02:04:12PM -0700, Som Bandyopadhyay wrote: > Hi, > > There used to be a list of webdav servers over internet kept some where ( along with their capabilities listed )...can someone point me to that list ? I don't seem to find the list any more ( only referenece I find is sharemation and riverfront's mention in www.webdav.org )...but their used to be a larger list. There is a short list partway down the page on http://www.webdav.org/projects/. Unfortunately, that page is rather out of date, but it is the only one that I know of at the moment. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Nov 30 20:51:33 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21784 for ; Thu, 30 Nov 2000 20:51:33 -0500 (EST) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA17718; Thu, 30 Nov 2000 20:30:25 -0500 (EST) Resent-Date: Thu, 30 Nov 2000 20:30:25 -0500 (EST) Resent-Message-Id: <200012010130.UAA17718@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA17676 for ; Thu, 30 Nov 2000 20:30:21 -0500 (EST) Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA09776; Thu, 30 Nov 2000 20:30:21 -0500 Received: from i41fs3.ira.uka.de by iraun1 (PP) with ESMTP; Fri, 1 Dec 2000 02:30:18 +0100 Received: from ira.uka.de by i41fs3.ira.uka.de id <02397-0@i41fs3.ira.uka.de>; Fri, 1 Dec 2000 02:28:26 +0100 From: "James J. Hunt" To: ietf-dav-versioning@w3.org CC: w3c-dist-auth@w3.org, reuterj@ira.uka.de Reply-to: jjh@ira.uka.de Mime-Version: 1.0 (generated by tm-edit 8.8 (Time Passed Me By)) Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 1 Dec 2000 02:30:14 +0100 Message-ID: <"i41fs3.ira.0039901:001201.012827"@ira.uka.de> X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id UAA17676 Subject: Draft IETF DeltaV Versioning Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4486 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by www19.w3.org id UAA17718 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA21784 Dear Colleges, From the experience we have gathered trying to implement the DeltaV protocol, we have some basic comments and suggestions to make before the end of the last call period for the DeltaV protocol. We regard these issues to be important for the future development of DeltaV and WebDAV. This message is cross posted to the WebDAV mailing list because the main points pertain as much to WebDAV as to DeltaV. Valid XML should be used in WebDAV instead of simply well formed XML ==================================================================== Using simply well formed XML misses half the benefit of XML: the automatic detection of syntactic errors. This is the best way to insure that a protocol stays open and correct. Any client or server can be easily tested for at least syntactic conformance. This does not means that every transaction must be validated, but ensuring that it can is important. On the WebDAV list, there has been some discussion about validating XML for WebDAV, for example, see http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0242.html. There seemed to be some agreement that the current WebDAV specification uses a syntax that is well-formed, but is not suitable for XML validation, and that it would not be too hard to make WebDAV to conform to XML validation rules. However, some participants did not agree on the advantages of validation. Interoperability is one of the key requirement on Internet protocols for supporting a heterogeneous network. This holds true for the WWW and its protocols including HTTP, WebDAV, and DeltaV. As WebDAV matures several extension protocols are emerging, among them the bindings and redirect-reference protocols, DeltaV, the access control lists specification, and the advanced collections protocol. All these extension protocols contribute to the XML syntax of WebDAV. Moreover, it is quite likely that vendors will introduce proprietary extensions to the XML syntax. For an idea of the extent to which this can occur, one just need look at the source code of the DeltaV specification at http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versioning-10.5.htm and notice all the tags inserted by Word that are not part of the HTML specification. All in all, the XML syntax of WebDAV can no longer be viewed as being simple. Validation can help us to identify bugs in WebDAV applications. Actually, this has already help us to find some bugs in the WebDAV specification itself (e.g. WebDAV issues DTD_BOOBOO, MISSING_NS_SPEC, cp. http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html). Validation may also force implementors to handle XML more carefully and thus improve reliability. Note that we do not want to force a WebDAV implementation to validate XML. We only suggest letting the implementor decide if and when to use validation. Currently, this is not possible without modifying an existing XML parser or writing a non-conforming XML parser. Therefore, we strongly suggest to fix the WebDAV specification and its extension protocols like DeltaV to conform to the XML specification--including XML validation. Then an implementor may choose when to apply validation. Another problem is to track version information about the protocols. The DAV header as returned from an OPTIONS request (e.g.: "DAV: 1, 2, version-selector-checkout") does not help at all. However, when using a DTD, the client and the server could agree on a protocol revision (or otherwise stop communication with an appropriate error message or log) by using the DTD's header information. Making WebDAV properties suitable for XML validation ==================================================== WebDAV currently expresses resource properties through a variety of tags, for example: Hello, world! In this example, the name of the property is "DAV:displayname", and its value is "Hello, world!". This approach has some disadvantages. First of all, if you want to list property names only, you currently have to do something like: But, in an XML DTD, an element can not be defined to have empty content and non-empty content at the same time. Hence, the way WebDAV currently handles properties is not suitable for validating XML. This problem has already been discussed as anomaly in the DAV:prop element usage (see http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0029.html). The simple solution here is to model the property name as an element attribute value or as PCDATA of a generic tag for all properties: Solution using XML attributes: - ------------------------------ Example: http://www.foo.bar Alternative solution without use of XML attributes: - --------------------------------------------------- Example: displayname source http://www.foo.bar DTD for DeltaV ============== Having all of the above said, DeltaV should, similarly to WebDAV, of course specify an adequate DTD for all elements introduced in DeltaV. The DTD need not be sent with every message. A reference to a URL at www.webdav.org would be sufficient. Labels in DeltaV ================ One of the recent changes in DeltaV was to remove labels from the core versioning part and put them into the options part of the protocol. We strongly suggest to undo this change. Even if there exist two or three revision control systems that do not use labels, labels are essential for identifying sets of associated files in a repository of versions. And, actually, they are really easy to implement (especially on top of a WebDAV implementation that requires built-in mechanisms for property storage). Sincerely, James J. Hunt Jürgen Reuter P.S. I will be at the IETF meeting in San Diego from the evening of the 10th to the early morning of the 15th to discuss these issues. --- JJHunt P.P.S I will send a second mail pertaining to smaller points we have discussed here that concern only DeltaV. --- Jürgen Reuter