Including additional properties in WebDAV PROPFIND/allprop requestsgreenbytes GmbHHafenweg 16MuensterNW48155Germany+49 251 2807760+49 251 2807761julian.reschke@greenbytes.dehttp://greenbytes.de/tech/webdav/greenbytes GmbHHafenweg 16MuensterNW48155Germany+49 251 2807760+49 251 2807761stefan.eissing@greenbytes.dehttp://greenbytes.de/tech/webdav/WEBDAV Working Group
Recent specifications extending the Web Distributed Authoring Protocol (WebDAV)
restrict the set of properties returned automatically upon a PROPFIND/allprop
request. This specification defines a method to add specific properties to
the set of properties returned upon PROPFIND/allprop.
Distribution of this document is unlimited. Please send comments to the
WebDAV working group at , which may be joined by sending a message with subject
"subscribe" to .
Discussions of the WEBDAV working group are archived at .
XML and HTML versions of this draft are available from .
Umbrella issue for editorial fixes/enhancements.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
Recent specifications extending the "Web Distributed Authoring Protocol" (WebDAV,
) like "Versioning Extensions to WebDAV"
and "WebDAV Access Control Protocol" restrict the set
of properties returned automatically upon a PROPFIND/allprop request in
order to avoid the expensive computation of properties that the client in many
cases isn't interested in.
However, this change from the behaviour defined in WebDAV can lead to
situations where clients need to perform two requests to retrieve all properties
they are interested in (one using PROPFIND/allprop, then PROPFIND/prop
enumerating the new properties that weren't reported upon the first request).
This specification defines a backward-compatible extension to add specific
properties to the set of properties returned upon PROPFIND/allprop, thus
saving at least one PROPFIND request.
This document defines an extension element that could ultimately become
part of the core WebDAV protocol. Being just an individual
submission, it currently defines it in the proprietary namespace
instead of the "DAV:" namespace. It uses a prefix of "in:"
for referring to elements in this namespace. However, WebDAV server and clients
are free to use any prefix, provided that there is a namespace declaration that
binds the prefix to the URI of the same namespace.
The "allprop" version of PROPFIND is extended to take an optional in:include
element.
When present, it contains a set of property names that shall be reported
in addition to those properties that the server usually would return upon
PROPFIND/allprop.
In this example, the server has recognized the extension element
in:include and included the properties DAV:checked-in
and DAV:checked-out (as defined in ).
In this case the in:include element was simply ignored. The client
can detect this situation by checking for the presence of the requested
properties and will have to issue an additional PROPFIND/prop request
(to retrieve the missing properties).
Note that the WebDAV DTD is informal only and cannot be used to validate
request or response bodies (due to the inability to properly work with
XML namespaces).
This specification introduces a new child element for the DAV:propfind
element, defined in . Old servers will ignore this
element (see , chapter 14). Clients can detect
this situation as outlined in .
Clients not aware of this specification will not be affected at all,
because they will never use the new in:include element in PROPFIND
requests.
This proposal builds on , and inherits its
internationalizability.
This proposal does not introduce any new IANA considerations, since
it does not specify any new namespaces (in the general sense), but
merely uses existing ones.
Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864-
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
HTTP Extensions for Distributed Authoring -- WEBDAVMicrosoft Corporationyarong@microsoft.comDept. Of Information and Computer Science, University of California, Irvineejw@ics.uci.eduNetscapeasad@netscape.comNovellsrcarter@novell.comNovelldcjensen@novell.comVersioning Extensions to WebDAVRational Softwaregeoffrey.clemm@rational.comIBMjamsden@us.ibm.comIBMtim_ellison@uk.ibm.comMicrosoftckaler@microsoft.comUC Santa Cruz, Dept. of Computer Scienceejw@cse.ucsc.eduWeb Distributed Authoring and Versioning (WebDAV) Access Control ProtocolIBM20 Maguire RoadLexingtonMA02421geoffrey.clemm@us.ibm.comgreenbytes GmbHSalzmannstrasse 152MuensterNW48159Germanyjulian.reschke@greenbytes.deOracle Corporation500 Oracle ParkwayRedwood ShoresCA94065eric.sedlar@oracle.comU.C. Santa Cruz, Dept. of Computer Science1156 High StreetSanta CruzCA95064ejw@cse.ucsc.eduHTTP Extensions for Distributed Authoring - WebDAV RFC2518 bisXythos Software, Inc. lisa@xythos.com IBMnnjason8451@smallcue.comHTTP Extensions for Distributed Authoring - WebDAV RFC2518 bisOpen Source Application Foundationlisa@osafoundation.orgIBMnnjason8451@smallcue.com
This section briefly describes an alternate approach to the problem covered
by this draft. It was discussed during the interim WebDAV working group
meeting in January 2003 and was supported by all meeting attendees.
It was also added to the latest draft for the revision of ,
.
Additional PROPFIND marshalling:
The DAV:dead-props element can be added to PROPFIND requests that retrieve
named properties using DAV:prop. When present, the server MUST include
all dead properties defined on the resource.
This example shows the alternate syntax applied to the example from .
At first glance, this extension seems to have equivalent semantics. On
closer inspection, it doesn't provide the client any means to actually find
out whether the remote server understood the extension (it can't distinguish
between "server does not now about "dead-props", and "there are no dead
properties on the resource").
Moved <include> element out of "DAV:" namespace.
Updated reference to deltaV (now RFC3253).
Changed examples to explicitly use utf-8 encoding for HTTP content type and
XML encoding.
Updated WebDAV ACL reference to draft 07.
Made sure figures fit in 72 columns.
Split references into "Normative" and "Informative".
Updated WebDAV ACL reference to draft 09.
Fixed XML errors in examples (wrong closing href tags).
Replaced domain names in examples according to RFC2606: "www.foo.bar" by
"www.example.org".
Shortened checked-in URI to fit into 72 characters in example.
Added short description of alternate syntax discussed during interim
WebDAV WG meeting (January 2003).
DTD fix for dead-props variant.
Remove superfluous IP and copyright sections.
Added reference to RFC2518bis. Updated reference to ACL draft.
Updated various references. Update abstract.
Updated RFC2518bis reference. Author's address updated. Added analysis of
shortcomings of the RFC2518bis approach.