2.1.13 WWW Distributed Authoring and Versioning (webdav)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-04

Jim Whitehead <ejw@cse.ucsc.edu>
Lisa Dusseault <lisa@xythos.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Ned Freed <ned.freed@mrochek.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.
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.
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.
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.
  • - draft-ietf-webdav-acl-09.txt
  • - draft-ietf-webdav-ordering-protocol-06.txt
  • - draft-ietf-webdav-rfc2518bis-03.txt
  • - draft-ietf-webdav-bind-01.txt
  • - draft-ietf-webdav-quota-01.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

    WebDAV Working Group Meeting
    San Francisco IETF, March 18
    Co-Chairs: Lisa Dusseault, Jim Whitehead
    Notetaker: Jim Whitehead
    A meeting of the IETF WebDAV Working Group was held at IETF-56, held
    in San Francisco. Approximately 25 people attended the meeting over its
    Lisa Dusseault began by going over the agenda. She noted that DASL
    discussion was dropped since there were not enough people present to
    discuss the issues in depth. Lisa then led a discussion of 2518bis.
    * Discussion of locking issues in 2518bis. Slide "Agreed text so far"
      - Discussion of the content type of the resource created by a LOCK
        when the content type doesn't exist. One thought: pick one type.
        Another choice: do whatever a server does when you send a PUT with
        no Content-Type header, and a non-empty body. Rough consensus:
        be silent on the issue (most likely defaulting to what happens
        when a PUT with no Content-Type header).
    * Discussion of the definition of a collection. Should we use binding
      terminology in 2518bis, or keep internal member terminology. Tempest
      in a teakettle over internal member terminology. In the end, decided
      to keep using internal member term.
    * Discussion of "First problem" slide. What should be the behavior on
      an UNLOCK on an indirectly locked resource (that is, an UNLOCK request
      issued to any resource in a locked hierarchy other than the one the
      original LOCK request was issued to)? Should the lock remove the
      entire depth lock, or should it be redirected, or should it fail?
      Rough consensus for failure, error code to be determined later.
    * Discussion of "Second problem" slide. When an If header is submitted
      against a depth locked resource, must a client use the lockroot URL,
      or is any URL in the locked tree OK? If the untagged If header's 
      to resource is the same as the request URL, will this break any 
      clients? One approach is to better identify interoperability failures
      in lock token handling. Need to make the text in the 
    specification in
      2518bis on the If header more clear. No consensus. Lisa will write
      a message to the mailing list summarizing both sides of the issue,
      and explicitly solicit feedback from Dan Brotsky, Julian Reschke, and
      Max Dunn on this, as well as generally from the mailing list.
    * Discussion of "what is locked" draft. Discussed effect of locks on
      live properties. Agreement of lock affecting dead properties. Also
      tentative agreement that a lock should affect all PROPPATCH 
      on all properties, live and dead. Briefly noted that locks do not 
      live properties from updating their values (e.g., 
      updating after a PUT -- this is OK, even when the resource is 
    * The "Last Piece" slide. No disagreement. Refined lock-root to
      "lock root URL" to avoid ambiguity over what "mapping" means.
    * "Allprop replacement proposal." Agreement in the room that the
      proposal listed on the slide was fine. Some concern over 
      implications of adding new XML tag into PROPFIND prop requests to
      ask for all dead properties.
    * Discussion on whether there should be an additional 4xx or 5xx status
      code for multistatus cases. Several viewpoints. Aesthetic: 207 is
      for complete success, while a 207 can have 4xx inside it, so this is
      a contradiction. Interoperability: clients may not know how to 
      handle a new 4xx that expresses a multistatus case, or only use the new
      4xx for cases where it is OK for the client to treat the entire 
      as a failure. Functional: some tools may not understand WebDAV, but 
      come into contact with 207 responses. An example is an HTTP logging tool
      that might be trying to tally success and failure, and won't properly
      handle 207. Rough consensus to *not* make any changes to 2518bis. Keep
      current semantics of 207, do not add new status codes.  Main 
      is to not break current implementations, or add a new status code that
      might cause interoperability problems.
    * Discussion of entity tags, and support level. Not strong support for
      moving to SHOULD. Roy Fielding argued that there is already strong
      motivation for supporting entity tags, since they provide 
      caching benefits. But, there is experience that many DAV servers do not
      support entity tags at all, and hence interoperability might benefit
      from language in the specification recommending, or giving a SHOULD
      level requirement on support of entity tags. Some agreement that use
      of entity tags should be RECOMMENDED (defined in 2119 to be the same
      strength as SHOULD) on all PUTable resources. Also makes sense to
      add an implementation note providing rationale for why entity tags
      are a good thing to implement.
    Brian Korver, discussion of Quota specification.
    Brian began with an overview of the latest draft of the quota
    specification. Some questions on the semantics of the new 
    Brian mentioned that the definitions were taken from the definition of
    the NSF quota system. The quota properties are strictly live. Quotas
    are defined on resources -- there is no mechanism to ask about the
    quota for a particular user.
    People who volunteered to read and review the specification.
    Jim Whitehead, a grad. student of Jim's. 
    Jim stated that the specification is close to WG last call, look for
    this in a few months, after a few people in the WG have read and
    provided feedback on the quota specification.
    Brief discussion of the ordering specification. Geoff Clemm 
    recent changes. Jim asked whether there were any objections to moving 
    this to a working group last call. None surfaced.
    Geoff Clemm then led discussion on the binding protocol.
    Geoff began with a brief overview of the binding protocol. 
    Discussion of copy language in the binding specification. No 
    on the language in the specification. Some discussion on Copy, Depth
    infinity case. *** Need to add description of the behavior of Copy, Depth
    infinity case, since it's not currently covered in the 
    Discussion of delete and bindings. Will take this to the list -- raised
    the issue.
    Binding specification is at a point where, if you have issues with the
    specification, they should be surfaced now. Will work to resolve open 
    issues soon, want to drive specification to closure in the near future.
    Geoff then led a brief discussion of the ACL protocol. Brief review of
    IESG feedback on the recent last call. There is a new draft in
    preparation, and will submit this as an I-D in the near future. Like
    binding specification, want to quickly move to closure on this.
    **end of meeting***
    ----------------INTERIM MEETING----------------
    1. Datatypes for WebDAV properties
    The basic idea is that a PROPFIND would provide type information for 
    dead and non-RFC2518 live properties. PROPATCH would similarly allow one 
    to specify data types in conjunction with setting property values.
    The approach uses the W3C XML schema type library and instance type 
    attribute to indicate types. This has the advantage of using a standard 
    and extensible type library (also used in many other 
    Additional property information to be considered includes:
    * 'hidden' flag
    * 'protected' flag
    * 'display name' attribute
    Open issues to be resolved:
    * marshaling of display name
    * relationship to document types and schema definitions of required 
    property sets
    Discussion on how best to proceed: initially develop the high-level 
    requirements, then move further discussion to a separate (new) mailing 
    2. ACL discussion led by Lisa Dusseault and Eric Sedlar
    Lisa Dusseault presented feedback received from the IESG on ACL:
    * Basic authenticaiont over SSL/TLS is a MUST level requirement
    * Methods should be mapped to specific permissions (in a table)
    * Flexibility in te secification is a source of risk. Humans will err 
    and poorly written clients will help them.
    Eric Sedlar then led further discussion on the spec.
    The semantics of ordering wrt granting/denying permissions needs to be 
    worked out. Proposal to use the NFSv4 approach. Also need to specify how 
    custom priveleges are expressed.
    The spec will be clearer and easier to implement correctly if the 
    language is stronger - use MUST level requirements wherever possible.
    3. Property registration, Dennis Hamilton
    There is a recognized need to record authoratative info on properties 
    and namespaces such as where to go (spec., company, etc.) for more 
    detail. There is also a desire to reduce the complexity of the spec as 
    much as possible.
    The focus of this effort is not machine-readable discovery of 
    properties, but future work may address this.
    On namespace registration and authority:
    * Namespaces SHOULD be registered and
    * namespaces SHOULD be resolvable.
    * Just anyone should not be able to register a property within a given 
    4. DASL discussion led by Julian Reschke.
    Current issue list:
    * Error marshaling
        - proposal to align the sepc with RFC3253
    * 'next n' results
    * type handling in query literals
        - proposal to add DAV:typed-literal operad carrying xsi:type 
    * language handling for queries on txt props
        - proposal not to do this
    * Collation sequence for text comparisons
    On 'next-n' results:
     - Currently various DBs do this very differently. Some save state, some 
    redo the query and throw away the first n results.  
     - Next n results is something we want in the spec.
     - servers should be allowed to generate static 
    results at some URL, but should not be required to do so.
    DASL type handling:  
     - QSD needs to handle DAV:typed-literal.
     - Attendees agreed to add DAV:typed-literal and make QSD a MUST level 
    On language handling: (Summary)
     - If a user wants a language sensitive comparison, then they should 
    specify that with a language operator. Spec. should be silent on this 
    when discussing other operators. 
    On collation sequence:
     - Not completely solved by Unicode
     - In DBs, collation sequence can be set with lang+territory but has 
    impact on performance, and one may need multiple indices.
     - Java allows a collation to be specified
     - Intend to use language from XPath/XQery, allowing lang 
    to be passed in and a URL to refer to collation info.
    Proposal to change name of casesensitive comparison operator to 
    caseinsensitive, which describes the behavior more accurately. No 
    objections from those present.
    On dates:
     - DASL spec only supports ISO dates. This is fine. RFC2518 supported 
    other formats, but only for compatibility with RFC2616.
    Contains operator: 
    The contains operator should work on properties... it is 
    the most frequently used search. To support that we would need to relax 
    wording in the definition of 'contains'. Maybe extending basicsearch is the 
    correct way to accomplish this?
    Other items:
     - No conclusions on typing operands vs. typing operators.
     - Error marshaling will follow RFC3253 
     - What does lte mean? can we be more specific in the spec?
     - Why is the use of "_ _" prohibited in a query? It shouldn't be a 
    to implement. The like syntax should conform to SQL'92 definition.
     - Ordering on mixed-content is undefined.
    Action item: Julian will be submitting another draft of the DASL spec.
    Tuesday - RFC2518 bis issues
    1) If header
     - Model needs to be fixed, so that servers behave more similarly
     - New syntax may not be necessary -- may be workaround.
     - Concern that the workaround "If (<locktoken> [and] NOT 
    <locktoken>)" will not work because of poorly implemented servers
     - Clients still want ability to send a PUT with a lock token, and if the 
    lock token is now gone, the request should not fail.
     - Jim proposed an "aggregate of locks" token, semantically the same as 
    Lisa's proposal to do "Locktokens-provided" header 
     - Action item: Julian will research whether the workaround actually can be 
    used with deployed servers.
    2) Requiring support for strong ETags
     - ETags are absolutely needed to prevent the lost-update problem.
     - WebDAV gateways (exposing a repository using WebDAV) can't easily 
    support strong ETags.
     - "Last one wins" behavior is what happens without strong ETags, but that 
    seems to be what users expect anyway.
     - Servers MUST return Not Found on the getetag property if they don't 
    support ETags properly.  Servers MUST NOT return empty or constant ETag 
     - Require Strong ETags on static resources supporting PUT, and must be 
    returned on GET
    3) Compliance testing
     - Some desire for more formal compliance testing suite
     - Litmus could be refined and publicized
    4) Clients forcing authentication
     - Servers don't send authentication challenge until 
    authentication fails on an operation (sometimes not until client has 
    already sent credentials)
     - Clients can't authenticate until they see the challenge
     - Clients need to authenticate to do a PROPFIND and see all resources that 
    user has permission to see, rather than only see publicly readable 
     - Will put Force-Challenge header in RFC2518bis
     - To solve other unauthenticated problems like PUT: Add information to 
    rfc2518 bis about how to use Expect header and how it must be 
    supported by servers 
    5) Walk through issues in 
     - CONSISTENCY: Note in 2518bis that all children of a WebDAV 
    collection are WebDAV resources. However, the parent of a WebDAV 
    resource may not be a WebDAV resource.
     - IMPLIED_LWS: will note in 2518bis that the rules in 2616 *do* apply
     - PUT_AND_INTERMEDIATE_COLLECTIONS: resolved "won't fix"
     - OVERWRITE_DELETE_ALL_TOO_STRONG: Needs more research
     - XML_LANG_CLARIFY: add notes to properties in 2518 which support 
     - 302_AND_MULTISTATUS: Julian will make specific syntax 
     - MKCOL_AND_302: Add note reminding that any method can respond 302
     - WHEN_TO_MULTISTATUS_FOR_DELETE_*: No need to change spec.
    Peter Tran, Ilya Kirnos, Julian Reschke, Stefan Eissing, Elias 
    Sinderson  , Raghu Pai, Jim Whitehead, Lisa Dusseault, Dennis 
    Hamilton, Eric Sedlar, Chris Knight - NASA Ames Research Center, 
    Guozheng Ge, Brian Korver, Jenessa Lin, Kai Pan, Tracy La, Andrew Sieja, 
    Greg Stein, Jim Luther, Ryan Parks


    Interim- ACL draft Issues from IESG Int. Session