W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RFC2518bis: allprop deprecated (4.1)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 21 Feb 2002 09:51:41 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCGEEGEBAA.julian.reschke@gmx.de>
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 Thursday, 21 February 2002 03:52:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT