- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Sun, 21 Apr 2002 11:19:29 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>
- Cc: Webdav WG <w3c-dist-auth@w3c.org>
Am Samstag den, 20. April 2002, um 22:15, schrieb Clemm, Geoff: > Just to follow up on this thread from a couple of months ago: > > I would be happy to see allprop defined as being: > "all 2518 props and all dead props". I also support the > allprop-include extension, but that would have to be > specified in a different standard track, since it is > new functionality (unless we can get some interoperable > implementations out there fast). I had an implementation of allprop-include at the last webdav interop in my webdav-proxy. It did not break any present servers (nor IIS/Sharepoint). So, I would encourage (especially Deltav/ACL capable client) developers to have a look at: http://www.greenbytes.de/tech/webdav/ //Stefan > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, February 28, 2002 12:22 PM > To: Webdav WG > Subject: RE: RFC2518bis: allprop deprecated (4.1) > > > Following up to my own post: > > the last WG meeting minutes (at > <http://www.ietf.org/proceedings/01dec/127.htm>) say: > > "What 'allprop' means.... > > MUST include all 2518 props and all dead props to maintain > interrop. However > new live props in ACL DASL etc are being defined as NOT returned > by allprop. > Property dead on one server may not be dead on another server. > allprop is > historical. Promote using propname. Is it legal for Xythos to use > the adobe > namespace? You could have a property that is defined dead on one > server be > live on another! > > allprop must return all properties required for interrop. > > Eric - property should be defined dead or non-nead...you can't mix and > match. > > Should we deprecate allprop? > Perhaps use allprop-include or other mechanism to save roundtrip and > deprecate allprop. Sitecopy properties would not be the same. Is > deprecate > something we can do in IETF? Take it out and reference them back > to the old > draft. Geoff - Short description plus reference back to old spec. > We took a > vote and 3 people would like it to become a info note, nobody > objected." > > > I'm not sure I understand what the last paragraph says. I > certainly do *not* > agree to remove allprop without replacing it with something which is as > efficient. See remarks in my previous mail. > > Julian > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke >> Sent: Thursday, February 21, 2002 9:52 AM >> To: Lisa Dusseault; Webdav WG >> Subject: RFC2518bis: allprop deprecated (4.1) >> >> >> Lisa, >> >> I don't agree at all with the deprecation, and I don't think that >> there was >> consensus about this. >> >> The draft says: >> >> Clients MUST not send allprop requests in any form (either the >> empty body >> PROPFIND or the specific allprop element), because allprop is >> being removed. >> WebDAV servers increasingly have expensively-calculated or lengthy >> properties (see DeltaV and ACL specifications [TODO: ref RFC when >> available]) and do not return all properties already. Instead, WebDAV >> clients can use propname requests to discover what properties >> exist, and >> request named properties when retrieving values. A WebDAV server >> MAY omit >> certain live properties from other specifications when responding >> to an >> allprop request from an older client, and MAY return only custom >> (dead) >> properties and those defined in this specification. >> >> In particular: >> >> "WebDAV servers increasingly have expensively-calculated or lengthy >> properties (see DeltaV and ACL specifications [TODO: ref RFC when >> available]) and do not return all properties already." >> >> -> This is an argument for *restricting* the set of properties >> returned on >> allprop, not for removing the feature (and that's what deltaV does). >> >> "Instead, WebDAV clients can use propname requests to discover what >> properties exist, and request named properties when retrieving >> values." >> >> -> And the benefit is? The client will issue two calls: first it >> will use >> propname to find the list of properties. Computing whether a live >> property >> exists maybe as expensive as computing it (for instance, to find >> out whether >> something is checked in/out). *Then* it will submit PROPFIND / >> prop will all >> these properties. So as compared to the current situation, the >> server may >> have to compute things twice which wouldn't have been computed at >> all before >> (since asking for allprop wouldn't require computing live deltaV >> properties). >> >> -> Even leaving the propname vs live properties issue out, this >> doesn't make >> sense. You are removing a working and interoperable protocol >> feature without >> sound reason. As a fallback you offer a workaround which requires >> at least >> one additional trip to the server, possibly heavy computation on >> the client >> (computing the set of all property names on the members of a >> collection) and >> then additional marshalling (when I do a PROPFIND/prop with a >> long list of >> (dead) property names on a collection with depth 1, the server >> will have to >> 404-status them for many collection members). >> >> -> I agree that PROPFIND needs to be cleaned up, but this is not >> the way to >> go. The draft continues with: >> >> "A WebDAV server MAY omit certain live properties from other >> specifications >> when responding to an allprop request from an older client, and >> MAY return >> only custom (dead) properties and those defined in this >> specification." >> >> -> I think this may make sense. We will however need a way to get >> all dead >> properties and a set of named properties with a single request >> (see [1]). We >> may also have to find a way for a client to discover that >> something is a >> live property. >> >> >> [1] >> <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-allprop > -include-l > atest.html> >
Received on Sunday, 21 April 2002 05:20:20 UTC