2.1.13 WWW Distributed Authoring and Versioning (webdav)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-16

Jim Whitehead <ejw@cse.ucsc.edu>
Lisa Dusseault <lisa@xythos.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Ted Hardie <hardie@qualcomm.com>
Applications Area Advisor:
Ted Hardie <hardie@qualcomm.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:
Done  Revise Access Control Protocol document. Submit as Internet-Draft.
Done  Meet at Pittsburgh IETF. Discuss Access Control Goals and Protocol documents. Discuss issues in WebDAV Distributed Authoring Protocol
Done  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.
Done  Revise Access Control Protocol, and Access Control Goals documents. Submit as Internet Draft. Begin working group last call for comments.
Done  Revise WebDAV Distributed Authoring Protocol. Submit as Internet-Draft
Dec 00  Revise Redirect References Protocol. Begin working group last call for comments.
Done  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.
Done  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.
Done  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.
  • - draft-ietf-webdav-acl-12.txt
  • - draft-ietf-webdav-redirectref-protocol-06.txt
  • - draft-ietf-webdav-ordering-protocol-10.txt
  • - draft-ietf-webdav-rfc2518bis-05.txt
  • - draft-ietf-webdav-bind-02.txt
  • - draft-ietf-webdav-quota-02.txt
  • Request For Comments:
    RFC2291 I Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
    RFC2518 PS HTTP Extensions for Distributed Authoring -- WEBDAV

    Current Meeting Report

    Notes for WebDAV WG meeting at IETF 58.  Thanks to Larry Greenfield for 
    notes/chat transcript.
    TOPIC: Agenda bashing
     - no objections
    TOPIC: ACL status
     - Security ADs did not approve and did not block. 
     - Now in the RFC editor queue.
     - major problem was the unbounded number of rights.
     - security ADs says nothing could be done to make this spec a good spec, 
    but weren't willing to make the WG restart.
     - hopefully "application acl workshops" will be held.
     - for future revs, think about "intersection" instead of "union" 
    TOPIC: Quota/size properties
    Brian Korver 
     - draft to let things interoperate with quota implementations.
     - -02 document aligns better with NFS.
     - quota_avail added back in to deal with low disk space condition
     - the thought is that a MAY for including disk space is ok.
     - we could remove from spec and a future application can give disk 
    Some additional questions on Quota 
    Q (Reschke): why are disk limits treated as quota when (a) NFS behaves 
    differently and (b) making a difference could enhance client error 
    handling (such as mapping to error codes in file system drivers)?
    A: some memory that WG members had asked for disk limits to be treated as 
    Proposal: marshall as separate properties, define distinct condition 
    codes, so that clients can distinguish both conditions (just like in file 
    Q: (Randy presuhn) Why do you need to know this number? 
    A: to not attempt operations that would almost assurdly fail.
    Suggestion (Reschke): For instance, we may just define a generic mapping of 
    RFC3530 properies to DAV properties, then apply that mapping to the two 
    quota and the two disk space properties defined there.
    TOPIC: Redirect draft.
     - issue: Replace MKRESOURCE with MKREDIRECT?
     - issue: allow authoirng 301-type redirects as well as 302-type?
     - issue: How to handle requests that address mutliple resources, 
    including redirects
     - no comments from attendees.
    TOPIC: Interop Report.
     - 4 clients, 6 servers. this is only about 30% of implementors.
     - possible to participate remotely 
     - also ongoing interop testing using "always online" test servers
     - Jim Luther @ Apple is maintaing a list of public test accounts
    TOPIC: RFC 2518bis issues
    Do namespace prefix tags need to be preserved
     - issue is with XML vocabularies that use prefixes in text or 
    attribute content, 
     - such as XSLT or XML Schema
     - "prefix rewriting") would break fragments of these vocabularies 
    appearing in properties
    Requirements for ETag support
     - question for ted: when going to draft standard, how hard do you try to 
    keep existing implementations compliant?
     - Ted: It's certainly possible that one or more implementations will 
    become uncompliant.  
     - if it changes behavior, then usually you recycle at propose.
     - other things are big changes, too.
     - you can remove features but you cant change features or add features 
    without recycling at propose.
     - Ted: the standard level isn't a big deal, so don't worry about 
    recycling at proposed. make the spec as good as possible.
    More commentary: 
    Suggestion (Reschke): It would be really good if some of the mod_dav 
    maintainers could state whether they are planning to actually meet the 
    stronger etag requirements.
    Q (OGeisser): are there any plans for "ptags" = "etags for 
    A (Lisa): Yes, or ctags = "ctags for collections": would rather not add 
    major new design to webdav, just make stronger compliance, simplify 
    features, etc.  New features that would be added in new extensions is the 
    thought here.
    (reschke): I certainly dislike the idea of having an RFC2518++ that isn't 
    supported by Apache.
    (Ted): send the source to apache to fix the issue, and that's done.
    Issue: Must resources be in collections
     - Consensus is that resources can be standalone. 
    Issue: Some interest in new writable modification-date property
     - for instance, a backup program could upload stuff to a server and set the 
    modification-date property from the original.
     - Jim Luther on the filesystem team here at Apple wanted this 
     - Changing getlastmodified considered dangerous
     - Note that setting DAV:getlastmodified *back* implies changing the MIME 
    header last-modified as well, and that may be a bad idea.
     - it could screw up things for intermediaries and caches, unless we 
    divorced the property value from the header value which might create more 
     - We may instead want to define a new property that can track 
    modifications to properties as well (that would resemble more closely a 
    filesystems last mod date)
    TOPIC: PATCH proposal
     - WebDAV use case: would make it easier to make small changes to very 
    large files.
     - DeltaV use case: small changes to many source files.
     - SIMPLE use case : changing my buddy list or presence document on HTTP 
     - Netconf use case: Making changes to large configuration documents.
    Q (OGeisser) does the PATCH proposal allow a partial change of a 
    property value, too (sorry - have not read the proposal)
    A: No
    Suggestion (Reschke): an alternative would be to model parts of a 
    resource as indivually addressable sub-resources (with their own URIs)
    Status is at 
    Reschke: My understanding is that we want to last-call the spec when the 
    open issue is resolved.
    Lisa has other issues which she will raise on list.


    Quota and Size Properties for DAV Collections