[RFC2518 Issue] PROPFIND 'allprop' usage

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

Received on Friday, 10 November 2000 13:38:27 UTC