2.1.14 WWW Distributed Authoring and Versioning (webdav)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


Jim Whitehead <ejw@cse.ucsc.edu>

Applications Area Director(s):

Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik Faltstrom <paf@cisco.com>

Mailing Lists:

General Discussion:w3c-dist-auth@w3.org
To Subscribe: w3c-dist-auth-request@w3.org
In Body: Subject of subscribe
Archive: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/

Description of Working Group:

The goal of this working group is to define extensions to the Hypertext Transfer Protocol (HTTP) that enable remote collaborative authoring of Web resources.

When the WebDAV working group was initially formed, it was reacting to experience from circa-1995/96 HTML authoring tools that showed they were unable to meet their user's needs using the facilities of the HTTP protocol. The observed consequences were either postponed introduction of distributed authoring capability, or the addition of nonstandard extensions to the HTTP protocol. These extensions, developed in isolation, are not interoperable. The WebDAV Distributed Authoring Protocol, RFC 2518, addressed these concerns by providing facilities for overwrite prevention (locking), metadata management (properties), and namespace management (copy, move, collections).

Despite their utility, several important capabilities were not supported in the initial Distributed Authoring Protocol. It is a goal to create protocols to support these capabilities:

* Referential Containment (Bindings): The WebDAV Distributed Authoring Protocol has unusual containment semantics where multiple containment is allowed, but not supported by any protocol operations, yet container deletion assumes inclusion containment, deleting the container and its members. Most object management systems provide full support for referential containment, and have delete semantics that only remove the container without affecting contained objects.

* Ordered Collections: Collection contents have a persistently maintained ordering.

* Namespace Redirection (Redirect References): HTTP, via its 301 and 302 responses, supports namespace redirection where a request on one URL is returned to the client with instructions to resubmit the same request to another URL.

* Access Control: Remote management of access permissions on Web resources.

Experience to date with WebDAV properties has suggested that interoperability of these properties would be improved by the creation of a voluntary, central registry of WebDAV properties. Procedures for registering new properties, updating existing property descriptions, and the contents of each registry item need to be detailed.

As with most application layer protocols, implementation and field experience on the WebDAV Distributed Authoring Protocol has highlighted many issues that should be addressed as the protocol is advanced from proposed to draft standard status. Some of these issues will require additional deliberation within the WebDAV working group.


The following items were initially identified as being out of scope for the WebDAV working group, and continue to be such:

* Definition of core attribute sets, beyond those attributes necessary for the implementation of distributed authoring and versioning functionality

* Creation of new authentication schemes

* HTTP server to server communication protocols

* Distributed authoring via protocols other than HTTP and SMTP

* Implementation of functionality by non-origin proxies

The WebDAV working group initially had a goal of supporting remote versioning operations as well. However, when this scope was found to be too broad, the DeltaV working group was formed. As a result, development of a versioning protocol is currently not in scope for WebDAV, though discussions related to compatibility between versioning and remote authoring are still in scope.


The final output of this working group is expected to be these documents:

1. A Bindings Protocol, providing a specification of operations supporting referential containment for WebDAV collections. [Proposed Standard]

2. An Ordered Collections Protocol, providing a specification of operations for manipulating and listing persistent orderings for WebDAV collections.[Proposed Standard]

3. A Redirect References Protocol, providing a specification of operations for remote maintenance of namespace redirections, and the interaction of these redirections with existing HTTP and WebDAV methods. [Proposed Standard]

4. An Access Control Goals document, providing a list of goals the access control protocol should meet, and not meet. [Informational]

5. An Access Control Protocol, providing extensions to WebDAV that allow remote control over the access rights for Web resources. [Proposed Standard]

6. A Property Registry, describing a process for registering WebDAV properties, and the contents of each registry item. [Informational]

7. An updated version of WebDAV Distributed Authoring Protocol that resolves known issues with the protocol. [Draft Standard]

At present, the Binding Protocol and Redirect Reference protocol have both been through a working group last call for comments process, and are very close to completion. The Ordered Colletions protocol has also had significant review, and is also close to completion. The access control, and property registry documents are new work, as is the revision of the WebDAV Distributed Authoring Protocol.

In addition to the IETF Internet-Draft repository (http://www.ietf.org/ID.html), the most recent versions of these documents are accessible via links from the WebDAV Home Page, (http://www.ics.uci.edu/pub/ietf/webdav/), and on WebDAV Resources, (http://www.webdav.org/).

Goals and Milestones:



Revise Access Control Protocol document. Submit as Internet-Draft.



Meet at Pittsburgh IETF. Discuss Access Control Goals and Protocol documents. Discuss issues in WebDAV Distributed Authoring Protocol



Revise Access Control Protocol document. Submit as Internet Draft.

Oct 00


Revise Binding Protocol document, submit as Internet-Draft. Begin working group last call for comments.

Nov 00


Revise Access Control Protocol, and Access Control Goals documents. Submit as Internet Draft. Begin working group last call for comments.

Nov 00


Revise WebDAV Distributed Authoring Protocol. Submit as Internet-Draft

Dec 00


Revise Redirect References Protocol. Begin working group last call for comments.



Meet at San Diego IETF. Hold a review of the Access Control Goals and Protocol documents. Discuss comments raised during working group last call for comments. Discuss issues in WebDAV Distributed Authoring Protocol.

Jan 01


Revise Access Control Protocol and Goals documents. Submit as Internet Draft. Submit Access Control Protocol to IESG for approval as Proposed Standard. Submit Access Control Goals to IESG for approval as Informational RFC.

Feb 01


Submit revised Redirect References protocol as Internet-Draft. Submit to IESG for approval as Proposed Standard.

Feb 01


Submit revised Ordered Collections protocol as Internet-Draft. Begin working group last call for comments.

Mar 01


Submit initial WebDAV properties registry document as Internet-Draft

Mar 01


Submit revised Distributed Authoring Protocol as Internet-Draft.

Mar 01


Meet at Minneapolis IETF. Discuss issues in WebDAV Distributed Authoring Protocol, and WebDAV property registry.

Apr 01


Submit revised Ordered Collections protocol as Internet-Draft. Submit to IESG for approval as a Proposed Standard.

May 01


Submit revised WebDAV properties registry document as Internet-Draft

Jun 01


Submit revised WebDAV properties registry document as Internet-Draft. Submit to IESG for approval as Informational RFC.

Jun 01


Submit revised Distributed Authoring Protocol as Internet-Draft. Begin working group last call for comments.

Aug 01


Submit revised Distributed Authoring Protocol as Internet-Draft. Submit to IESG for approval as Draft Standard.

Request For Comments:






Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web



HTTP Extensions for Distributed Authoring -- WEBDAV

Current Meeting Report

WebDAV Working Group Meeting (1:30pm Monday August 6th, 2001)
IETF'51 London, England

Lisa Dusseault standing in for Jim Whitehead as Chair.

- Lisa D. presented the agenda and it was approved by the group.

- Discussion started with DASL. Lisa D. is taking over the role of editor, and has tried to contact previous authors without much success. Lisa D. made a call for participants on the DASL spec.

- Larry M. asked if the XML query language from W3C is sufficient for DASL. Lisa thinks it is solving a different problem and that an SQL-like syntax is more appropriate for DASL.

- Should include discovery so that the server can answer which properties it supports searches over. Nobody stood up for schema discovery.

- How about search over content? Should be in scope of the working group, but should it be a requirement of DASL?

- IETF process ? should DASL be part of the WebDAV WG or be in a separate WG or be an independent submission? People agreed that it should not be part of the WebDAV WG. ACLs were in the WebDAV WG charter, DASL isn't.

- Question: What remains to do in the WebDAV WG charter? Advanced collections, redirect references, properties registry doc., ordered collections, and raising DAV to a draft standard.

- This remaining work is probably just lacking an editor/champion. The WG should push them forward or drop them if there is no interest in the work being done.

- Larry M. presented the WebDAV Inter-op report. 58 people, 20 organizations, 35 implementations, (17 clients, 18 servers of which 5 open source).

- Participants had agreed not to publish the results for individual tests.

- Not many implementations inter-operated completely without any issues.

- The event made good progress towards inter-op., some teams made fixes in real time either on-site or in collaboration with development teams 'back home'.

- Proposed a virtual inter-op meeting in late-September, say a four hour test window and a telephone conference call.

- Mailing list for inter-op discussions is interop@webdav.org, which is by invitation.

- Found common inter-op problems, maybe these can be distilled into an implementers' guide.

- Little, if any, DeltaV testing took place.

- Typical problems include security, URI encoding problems, etc. misunderstandings in the spec.

- Inter-op testing uncovered some required features were missing. Many servers did not implement LOCK, and many clients required it.

- Some inter-op problems were HTTP issues, such as authentication, multiple authentication headers.

- Missing, unused, untested features included DAV:source property (nobody used or implemented it), content-language being reflected in the DAV:getcontentlanguage property. It was noted that the source property should be removed unless there are min. two independent interoperable client and server implementations of it. Jim A. pointed out that the DAV:source property is simply a dead property containing an HREF, there should be nothing difficult to implement it. Translate header was used in place of the source property by some implementations. It is a Boolean switch to tell the server whether to interpret the resource or not.

- John S. asked if people had considered using simple URL mangling to indicate the source, such as in PHP's .phps

- Poor support for the lang attribute on properties. Maybe it is not used because there is some ambiguity over it in the specification?

- The "property behavior" element in MOVE/COPY may not have been tested.

- Discovering the root of the repository. Some clients relied upon "OPTIONS /" to respond with DAV information, although servlet implementations would require at least a URL segment. So should clients not rely on "/" being in DAV-space? Clients may use other means of determining the root of the repository. One suggestion [from the floor] was to use the authentication realm.

- Security issues included those who use authorization headers from one request with subsequent requests on the same connection.

- Cookies in WebDAV. Some servers require that client support cookies, i.e. for session look-up rather than re-authentication. Clients should not be expected to support cookies, but in these circumstances clients should support cookies if they expect performant servers. This is material for the implementer's guide.

- Lock-null resources. LOCK followed by PUT, and LOCK followed by MKCOL are both required to be supported according to the spec., but no clients required the LOCK followed by MKCOL behavior. Consider dropping this from the spec.

- LOCK followed by UNLOCK should cause the lock-null resource to disappear. Varying implementations were seen.

- Support for "If-None-Match: ?" is unknown.

- Discussion of status code when creating a lock-null resource, should it be 200 or 201?

- Maybe lock-null resources should have a discrete MIME-type to distinguish it as a special resource. However, some server platforms don't remember the MIME-types but rely on the file extensions.

- Lock permissions. Lock operations by non-lock creator. Should there be a principal in ACLs that allows 'lock stealing'? Servers should only allow privileged UNLOCK.

- If: header confusion. Issues surrounding the size of the header value when dealing with deep collections, and combination problems. When combining values does it mean logical AND or OR? Jim A. to post grammar for the If: header onto the list.

- URL escaping ? how to deal with href illegal characters eg., "?/New Folder", are they XML escaped or URL escaped or both, and in what order, e.g. UTF-8 encoding and HEX encoding. Recommended to take a look at Donald's refs to DSIG document on canonicalization.

- (At this point the curtain falls and nearly crushes Lisa)!

- Where does the xml:lang attribute go? Does anyone care? Maybe should state that implementations should support it anywhere as XML generators may move it up to the root. No objections to putting the lang attribute on the DAV:prop element.

- Servers should return URLs with a trailing slash when referring to collections, however, clients should not rely on it. Consider making the standing convention stronger?

- Note that URLs returned in a multi-status may be relative to the content-location returned in the response ? should be in the implementer's guide.

- Date format: page 27 of the RFC2518 stands. Implementations should follow the spec in this regard.

- Lock owner information. Should servers take the information passed by the client, or use information they know based on the client's authenticated principal? Agreed that the server should take the information passed by the client, and maybe augment the lock token information with "creator" as well.

- Should clarify which properties are live and which are protected.

- Meeting closed at 5:30pm.


None received.