Motivation for draft-stracke-webdav-propfind-space-00

Someone asked me offline what problem
draft-stracke-webdav-propfind-space-00 was meant to solve;
apparently my vague appeal to "A WebDAV application using a
custom namespace for application-specific data" wasn't good
enough.  :-) Unfortunately, the application that required the
extension is not yet public knowledge, but I can provide a couple
of other scenarios.

First, a bandwidth argument.  Consider a Dublin Core application
which is using draft-ietf-webdav-dublin-core (or something like
it) to store DC metadata on a WebDAV server; it doesn't care
about non-DC properties.  It may prefer to send:

     <allprop>
     <namespaces>
     <namespace>http://purl.org/dc/elements/1.0/</namespace>
     </namespaces>
     </allprop>

rather than a <prop> listing the 15 DC elements.

Second, consider the same DC application, except now it's also
extensible: it wants to provide some minimal functionality for DC
elements which did not exist when it was written, so it provides
a UI to manipulate them, even if it can't tell the user what they
mean.  In this case, if it's using base WebDAV, it can't get
every property in the DC namespace without getting every
property, period.  It could do a <propname> followed by a <prop>
with all the property names it finds, but that's going to be
really inefficient, since it requires two round trips.  The
<namespaces> extension enables it to get just the properties it
wants, in one round trip.

Third, consider a WebDAV server which is exposing some
application-specific dataset as WebDAV resources.  This dataset
includes a property store which (for its own reasons) does not
permit listing all properties; it can only list properties in a
specific namespace.  When an <allprop> comes in without a
<namespaces>, the server can't provide any properties from that
store.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |The Net was designed to survive nukes, but not|
|francis@ecal.com|lawsuits. Wait a minute.                      |
\===============================================================/

Received on Tuesday, 21 September 1999 10:07:46 UTC