2.1.14 WWW Distributed Authoring and Versioning (webdav)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00


Jim Whitehead <ejw@ics.uci.edu>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.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:

Jul 00


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

Sep 00


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.

Dec 00


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 minutes
Lisa Dusseault, acting WG chair
Dec 13, 2000 3:30-5:00 PM, San Diego
Reported by Larry Masinter


25 min: improved status reporting (Lisa)
50 minutes: Open issues & review of Access control
40 minutes: DeltaV report on things of general interest

Advanced Status Reporting

Presentation by Lisa Dusseault [Slides available separately]

The group discussed

(1) is there a problem with adding bodies to responses? Sense of the group was probably not, since IIS5 and apache already do. Sense of the group was also that clients should advertise their support for advanced status reporting so that server can be sure not to send back unwanted information.

(2) A discussion of whether the XML response should replace HTML bodies or be added to it. To be taken to list.

(3) response-detail could be added to 207 Multi-status body

(4) add language tag to <user-text> was agreed to be necessary

(5) discussion of registry of message codes & tags, and whether there's a registry, what clients that don't understand details could do besides presenting user text.

(6) consortia could get together and define user tags

(7) syntax of lang tag is wrong in example

(8) suggestion to use "application/xml" in the examples instead of "text/xml" sense of the group _seemed_ to be to continue in the model established by webDAV (text/xml) but further comments welcome

(9) Some servers translate status codes to HTML. Roy suggested that HTML could be augmented by adding an XML island inside the html. On the other hand, Sean pointed out, it's not trivial to locate an xml island within HTML. Lisa pointed out that if clients can ask for advanced error reporting rather than the default, they likely prefer straight XML and will construct their own presentation therefrom.

(10) 207 gets used for a wide variety of things latest proposal adds to 207

(11) Whether status-codes should be marked with error-level, e.g. fatal vs. warning vs. informational Group consensus: no, because such information is already in the error code used in the header of the response (100-level informational, 200-level success at least partial, others are probably fatal)

Summary: Most of the advanced status reporting proposal seemed acceptable, and work will proceed. Lisa Dusseault to produce an Internet-Draft.

ACL Open Issues & Review

Led by Eric Sedlar, Oracle

First gathered an issue list, then tackled issues one by one as follows:

- Authentication ID and general use thereof

It was asked whether we could use the "Authentication ID" as a way to identify owners of locks & other concepts that involve identifying users.

The response was that there was no reason why one couldn't reuse "Principal URL", but don't use authentication ID. The Principal URL is a common piece of information, a GUI might throw it up in a common way. However, it's outside the scope of the ACL draft to deal with using Principal URL for locks.

- Principal collection set as a new property

Why have this new collection? Answer: the principal URLs will live in a certain location, so it might be useful way of discovering principal URLs. There was discussion about whether WebDAV is being used for LDAP. Answer: this is just a hint to browser about which set of principals that might be useful to set in an ACL.

It was clarified that there can be more than one such principal collection set.

It was clarified that the URLs in this property could be LDAP URLs rather than point to a DAV collection of Principal URLs.

The "principal resources" in the principal collection set might allow propfind or might not. Sometimes a principal is just a URI and sometimes it has properties associated with it. At any rate it's intended to be read-only for the purposes of this draft.

It was decided that DAV:owner is already defined, so we can't make it use Principal URL.

It was proposed that ACL draft marshal principal-collection-set via OPTIONS instead.

It was suggested that principal usage should be consistent: either they are just hrefs, or a principal element & subelement.

- OPTIONS usage w/ACLs (brought up by Barry Lind)

In the current draft, read privilege does not control the OPTIONS method. Native Web servers don't do OPTIONS. It was proposed that we strike the requirement that READ doesn't control OPTIONS, and that <dav:read> should be able to cover the OPTIONS request.

- Matching current user with a principal

Anne raised an issue on section 5.4.1 of the ACLs draft. Must a unique ID be supplied? Answer: Text may need to be clarified.

- Standard ACL privs

Should <readacl> apply to reading the <current-user-priv-set> property which is ACL related? (this property lists the privileges I am currently granted on the resource) Discussion: Access to entire ACL is different than just asking "what I can do", thus doesn't need to be restricted in the same way. It's likely a calculated property. There may not be enough uniformity to make this a standard. Maybe we should specify these as separate operations, gated by separate privileges.

Or should access to another user's privileges on a resource be governed by a separate privilege instead?

Tentative decision: <dav:readacl> only applies to ACL property (not current-user-priv-set). Further discussion on list.

- Privilege extensibility

Read & readacl privileges are separate. Can a server define something else entirely and not use either 'read' or 'readacl'? What's the point of having a standard list of privileges if some of them don't have to be supported?

Eric explained, a conforming application will have to support all of these privileges, but some may be abstract. The client can discover which privileges are abstract by querying the server for the privilege tree. A priv that's abstract is one that can't be sent by client. Abstract is just a way of saying that you can't set it in the ACL.

Sean pointed out that the client will always have to parse the privilege tree in order to parse ACLs. This changes how you're going to be thinking about ACL protocol design, and it might affect client GUI design.

- Getting <current-user-priv-set> for users other than current user

This may be of limited usefulness, because admins can already look at the ACLs. Maybe this would be useful, but not useful enough. Todays file system implementations don't let you do this. It's hard to implement, even current-user-priv-set is hard to implement.

- ACL semantics (or, should we have a UNIX-style token)

Currently we have tokens to inform client of restrictions on ACLs, e.g. that the max numberof ACEs the server supports is 3 or to inform client what order they must be in. However, there aren't enough tokens, or of enough flexibility, to make client understand the limited UNIX-style permission set of RWX (read/write/execute) for self, group and public.

One option: we could have tokens that indicate the ACL can only name 1 group and 1 user. There is likely a set of common constraints that you might expect several varieties of ACL systems to have.

Other option: we could have a token that basically says "use UNIX-style". But, if we did this, where do we stop? A token for every unique ACL system?

This needs further discussion, but general feeling seemed to be to stick with the "constraints" tokens rather than move to "platforms" tokens.

- Separate priv. for write-owner and write-ACL

Brief discussion which seemed to answer open question

- Properties vs. Methods

The discussion at the last webdav meeting seemed to end with the decision that the ACL property would be set with a custom method, but read with PROPFIND. This was a compromise to make everyone shut up.

Arguments included:
- Pro custom write method: One shouldn't want to set ACLs via PROPPATCH since it's less flexible than a custom method.
- All proxy support/blocking arguments ruled out of scope by Lisa.
- Pro PROPPATCH: Existing DAV APIs use PROPPATCH. It's much easier for a client to support a new standard property with PROPFIND and PROPPATCH than to support a custom method.
- Pro custom read method: clients that want to do caching of property values could screw up with live properties
- Pro PROPFIND: fewer round-trips to get information about a resource.
- Pro PROPFIND: very handy to get multiple properties from multiple resources using depth PROPFIND.
- Pro custom write method: Sometimes it's very hard to set two properties that have side effects in the same request.

E.g. "turn versioning on" and "set the ACL" -- which applies first? Thus PROPPATCH adds difficulties. This argument was then countered: one could always just specify that certain live properties could be specified as "must be proppatched alone", and this would meet the transactability requirements.

- Pro custom write method: Updating live properties is often intended to have side effects, whereas proppatching dead properties doesn't. But the client can't tell the difference between having set a live property and a dead one, the server responds the same either way to a PROPPATCH. Thus, a custom write method is required so the client can be sure the server has done what it intended.

It was suggested a server could support both: it could allow PROPPATCH and the custom method.

Final suggestion to stick with current proposal, and wait for implementation experience to decide whether writing properties is good.

The name "right" vs. "privilege" & "permission" will be discussed offline.

"DeltaV report on things of general interest,"

This quick discussion was on features or methods required in DeltaV that might be more broadly applicable, thus deserved explanation to the WebDAV group as a whole.

Geoff Clemm, Jim Amsden

(1) "Comment" and "creator display name" properties have been added in DeltaV but may be generally useful.

(2) "Update: yes" vs. "Overwrite: yes" vs. "Overwrite: update" Rather than define a new value for the Overwrite header, it was decided to propose a clarification to 2518, indicating that it's not necessary to do a DELETE before an Overwrite: T operation.

(3) New response bodies included on 403 and 409; very similar to advanced status reporting discussion (and intended to interoperate)

(4) Options request now takes a body: Roy pointed out it's supposed to.

(5) Report method, which marshals large sets of information from the server. The intent with the REPORT functionality was to be able to ask for information that the server knows how to generate. The goal is to have a set of defined layouts of read-only information. DeltaV decided not to use (abuse?) POST for this feature, because it's just request for information. But unlike PROPFIND, parameters need to be sent along with the name of the report being requested. Rather than modify PROPFIND to add this extra information, DeltaV designed it to be a new method.