2.1.12 WWW Distributed Authoring and Versioning (webdav)

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

Last Modified: 2004-06-15

Lisa Dusseault <lisa@osafoundation.org>
Joe Hildebrand <jhildebrand@jabber.com>
Applications Area Director(s):
Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>
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. This is the third charter for this Working Group, and does not include items that have already been completed by this Working Group (base WebDAV Proposed Standard, ordered collections extension, and access control extension).

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.

* 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.

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 further 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. 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 updated version of WebDAV Distributed Authoring Protocol that resolves known issues with the protocol. [Draft Standard]

At present, the Binding Protocol and Redirect Reference protocols have been through a WG last call but major changes were made and another WG last call seems advised. The revision of the WebDAV Distributed Authoring Protocol has been started.

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.
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
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.
Done  Submit revised Ordered Collections protocol as Internet-Draft. Begin working group last call for comments.
Done  Meet at Minneapolis IETF. Discuss issues in WebDAV Distributed Authoring Protocol, and WebDAV property registry.
Done  Submit revised Ordered Collections protocol as Internet-Draft. Submit to IESG for approval as a Proposed Standard.
May 04  Revise Binding draft, submit as internet-draft. Begin working group last call.
Jul 04  Revise Redirect references draft. Begin working group last call.
Sep 04  Revise Binding as necessary, submit to IESG for approval as Proposed Standard.
Oct 04  Close more open issues in new draft of revised base protocol (RFC2518bis). Consider WG last call.
Oct 04  Revise Redirect references as necesssary, submit to IESG for approval as Proposed Standard.
Dec 04  Submit revised base protocol (RFC2518bis) to IESG for approval as Draft Standard.
  • - draft-ietf-webdav-redirectref-protocol-08.txt
  • - draft-ietf-webdav-rfc2518bis-06.txt
  • - draft-ietf-webdav-bind-06.txt
  • - draft-ietf-webdav-quota-03.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
    RFC3648StandardWebDAV Ordered Collections Protocol
    RFC3744StandardWebDAV Access Control Protocol

    Current Meeting Report


    Introducing Joe Hildebrand as co-chair

    Agenda bashing

    Review of outstanding drafts

    Reivew of RFC2518bis

    Last updated July 04 (version -06), recent changes mostly clarify lock behavior.

    Pass through beginning of issue list:


    - 12 COMPLIANCE_RESOURCE: Agreed to add a brief description to the text describing why we discuss compliance on a per-resource basis. Try to remove references to server compliance.This affects as bind as well and we may need to think about that some more.

    - 14 DEFINE_PRINCIPAL: The term "principal" is never defined in the WebDAV specification, or the HTTP or Digest specifications. It should be defined. It is defined in the ACL RFC -- copy and paste to RFC 2518.

    - 29 MKCOL_AND_302: The specification is ambiguous on the handling of 302 by MKCOL. It should explicitly state that MKCOL is redirected by a 302. We discussed whether all methods should be redirected by a 302, not just MKCOL. Lisa added a section to RFC2518bis that covers MKCOL as well as other methods, so possibly this should be closed.

    - 30 IMPLIED_LWS: The specification should explicitly note that the HTTP implied linear whitespace rule also applies to productions in the WebDAV specification. This is in 'bis' already.

    - 31 PUT_AND_INTERMEDIATE_COLLECTIONS: HTTP/1.1 allows PUT to create intermediate collections during PUT operation. WebDAV explicitly forbids this. This may cause problems with non-DAV-aware HTTP/1.1 authoring clients which depend on this behavior, even though the behavior is not guaranteed by HTTP/1.1 PUT. Although we've never seen HTTP clients try to PUT files on WebDAV servers, we agreed it could be useful to have a HTTP backwards-compatibility section in WebDAV.

    - 32 INTEROP_DELETE_AND_MULTISTATUS: An HTTP/1.1 authoring tool which issues a DELETE to a WebDAV server might receive a 207 MultiStatus response, which it would not understand. Following rules in the HTTP specification, it would then treat the 207 as a 200 (OK), and incorrectly assume the operation succeeded. Same as previous issue.

    - 33 OVERWRITE_DELETE_ALL_TOO_STRONG: A COPY or a MOVE with Overwrite set to True will perform a DELETE with Depth infinity at the destination of the operation. However, in the same situation, most OS's will perform a merge, rather than a DELETE. It is feared the DELETE is counter to user's expectations. Note that many OSes will warn before delete. We also realize this is not implemented as specified in some implementations, and should find out if the implementation community is split. Roy pointed out that a resource may be something other than a file or directory, that's why the rules can't simply be the same as a file system -- there was no disagreement.

    There were a couple suggestions how to handle this:

    - could have 3 states: true, false, merge (Joe)

    - If the server can't figure out how to do it, then return instructions as to how you do things (Brian Korver)

    - A client can always use "overwrite=false" and handle their own merging. (possibly Roy) Lisa pointed out that none of these approaches would actually make things more interoperable except possibly the last -- new mechanisms might not be implemented for this corner case.

    The other issue with this issue is that DeltaV explicitly prescribes something different on COPY to a versioned resource. Does this mean it's inconsistent with webdav? Lisa said maybe according to a strict definition, but at least it works better (otherwise a non-versioned client could cause a versioned file to go away). Larry asks if a client will see different behavior because a DeltaV server handles the COPY -- but we think that the differences will not be detectable to a non-DeltaV client, because DeltaV only redefines COPY to versioned resources, not to collections.

    So, do we have to change any text in this spec because of this? Lisa suggests we could change the text to put fewer constraints on futuure specs but otherwise explain to implementors that they should follow the spec wording for normal WebDAV resources.

    - 34 WHEN_TO_MULTISTATUS_FOR_DELETE_1: If a DELETE is issued to a collection, and it fails on all resources contained by the collection, and on the collection itself, a server should report just a single 4xx status code. But, instead the definition of DELETE indicates it should return a multistatus since an error occurred on a resource other than the Request-URI. The language needs to be tweaked so a multistatus is not required in this case. Lisa thinks this is already the case in recent versions of RFC2518bis.

    - 35 WHEN_TO_MULTISTATUS_FOR_DELETE_2: If a DELETE is issued to a collection, and it succeeds on all resources except the Request-URI, then it is OK for the server to report a single failure code. A multistatus response should be returned instead, and the language of DELETE should be tweaked so this is the case. Lisa thought this issue was a little confused.

    - 36 DATE_FORMAT_GETLASTMODIFIED: RFC 2518 specifies that the DAV:getlastmodified property must have the format specified by the HTTP-date production in RFC 2068. However, HTTP-date allows three date formats, rfc1123-date, rfc850-date, and asctime-date. Since RFC 2068 requires clients to accept all three time formats, this creates some ambiguity for whether WebDAV clients should also accept all three. The WebDAV specification should be updated to clarify that only the rfc1123-date production should be used in DAV:getlastmodified. No disagreement.

    - 37 DEEP_LOCK_ERROR_STATUS: Section 8.10.4 states that if a lock cannot be granted to all resources in a hierarchy, a 409 status response must be issued. Yet, the example in section 8.10.10 which demonstrates this uses a 207. Already fixed in RFC2518bis.

    - 38 OVERWRITE_DELETE_ERROR_STATUS: If a COPY or MOVE is submitted on a collection with Overwrite=T, if an error occurs during the delete processing associated with the Overwrite header, causing the entire operation to fail, what status should be returned? In the discussion, it seemed that using the 207 response with individual response codes for each resource was the correct approach, and Lisa needs to confirm that the spec is clear on this.

    - 40 LOCK_ISSUES: skipping for now

    - 42 MULTISTATUS_FROM_MKCOL: If MKCOL is submitted with an entity body, as permitted by RFC 2518, to create a collection and populate it, then it would make sense to return a 207 Multistatus for errors. This possibility should be made more clear in the specification. This was seen as just a clarification, seems reasonable (Joe)

    - 44 REPORT_OTHER_RESOURCE_LOCKED: In some cases, such as when the parent collection of a resource is locked, a 423 (Locked) status code is returned even though the resource identified by the Request-URI is not locked. This can be confusing, since it is not possible for a client to easily discover which resource is causing the locked status code to be returned. An improved status report would indicate the resource causing the lock message. Lisa reported that the list consensus is to add bodies to error codes to provide more information to the client, and this is in -06.

    - 47 COPY_INTO_YOURSELF_CLARIFY: RFC 2518 doesn't explicitly specify how to handle the case where a COPY with Depth infinity has a destination that is within the source hierarchy. For example, a COPY of Depth infinity of /A/ into /A/B/. One resolution is to state that the copy must behave as if the resources are first copied to a temporary location, then moved from the temporary location into the destination.

    - 49 EXTEND_UNDEFINED: The definition of the DAV header in section 9.1 uses a production called "extend", which is undefined in either this, or the HTTP/1.1 spec.

    Side discussion ensued on remembering to run the *BNF checker before submitting. The checkers use 2234, so we might want to use that. Definitely check RFC Editor errata.

    - 50 PUT_ON_COLLECTION: Currently, the language in section 8.7.2 does not state that a PUT is permitted on a collection. On the flip side, it doesn't state that this is forbidden either. It's just silent. The spec. should explicitly state that PUT is (or is not) permitted on a collection. The intention of RFC2518 was to leave this silent, and there was no objection in the room to continuing to be silent about PUT on collections. This issue should be resolved as closed (rejected) unless the mailing list overturns this.

    - 51 LEVEL_OR_CLASS: When describing compliance, the terms "level" and "class" are both used in the specification. Section 9.1 uses the term "level", while Section 15 uses the term "class". The specification should pick one and be consistent. -- which it already is.

    - 52 LOCK_BODY_SHOULD_BE_MUST: Section 8.10.1 states that a LOCK method request SHOULD have an XML request body. This SHOULD should instead be MUST. It was explained that recent list discussion concluded that a LOCK request that has a body is a request for a new lock, while a LOCK request without a body is a request to refresh a lock. Thus, this issue can be resolved as overtake by events.

    - 54 IF_AND_AUTH: The fact that use of authentication credentials with submission of lock tokens is required should be strengthened in the document. Lisa said that sometimes as author it's hard to know if you've succeeded in "clarifying" something Joe said we shall ask for verification that the clarification clarified the matter.

    - 55 DISPLAYNAME: There is confusion over the definition and use of the displayname property that has led to varying implementations. The default value of displayname should be specified. The behavior of displayname when there are multiple URLs for the resource needs to be clarified. this definitely needs to be taken to the list.

    - 56 DEPTH_LOCK_AND_IF: The specification is currently silent on how to use the If header for submitting a locktoken when performing a DELETE in a Depth infinity locked collection. Should the If header have both the collection URL and the Request-URI, or just the Request-URI? An example of this is needed. Lisa responded that 2518bis does have some clearer text on this so far, but more work might be needed.

    - 57 LOCK_SEMANTICS: At present, the WebDAV specification is not excruciatingly explicit that writing to a locked resource requires the combination of the lock token, plus an authentication principal. At one point, the spec. discusses an "authorized" principal, but "authorized" is never explicitly defined. Lisa believes as author that this is probably clearer now.

    - 59 PROPFIND_INFINITY: If a client quickly submits multiple PROPFIND, Depth: infinity requests to the top of a collection tree containing many resources, it effectively forms a denial of service (DoS) attack. Though this is noted at a high level in Section 17.2 in Security Considerations, the specific risks of a large PROPFIND should be noted there. Additionally, the specification should note whether a server is allowed to have a configuration option to disable Depth: inifinity PROPFINDs. It has been recommended that 403 (Forbidden) be returned if a server does not support Depth: infinity PROPFIND. Integer values other than 0 and 1 in PROPFIND requests were also proposed. Lisa suggested that we could make it clear that 503 could be used (from HTTP) in many situations.


    - 61 RESOURCETYPE_EXTENSION: Both versioning and access control have a need to have multiple values within the DAV:resourcetype property. The specification needs to explicitly state that these multiple values are allowable, and that clients should expect this. At least one example should demonstrate that.

    - 63 LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY: Is the complexity of the IF header appropriate for the simple task of verifying that a client knowingly owns a lock? The IF header seems to serve a different purpose. One of those purposes is for the server to verify that you have the lock token (and that you know the root of it?). Another is for the client to check some preconditions before doing an action. Another seems to be to specify what lock to refresh in a lock refresh request. This seems to create ambiguity in our definition of the semantics of the IF: header. There was general agreement that it is too complex but that's the way the protocol is, presumably because it's not bad enough to want to break backward compatibility.

    - 64 OPTIONS_RESPONSE_VARIES_FOR_RESOURCES: Should the response for an OPTIONS request be expected to vary from resource to resource? What should we proscribe? What about an example for file, directories and null resources? We agreed that options vary from resource to resource, but believe that this is clear now that extensions to WebDAV exist and show how to use OPTIONS better.

    - 65 UNLOCK_WHAT_URL: What do you return if the unlock request specifies a URL on which the lock does not reside? What if it's on a URL that is locked by the lock, but it's not the resource where the lock is rooted? Agreed that we seem to have preconditions for this now.

    - 66 MUST_AN_IF_HEADER_CHECK_THE_ROOT_OF_URL: Right now the server uses the IF: header to verify that a client knows what locks it has that are affected by an operation before it allows the operation. Must the client provide the root URL of a lock, any URL for a pertainent loc, or some specific URL in the IF: header. Lisa thinks this is clarified

    - 67 UNLOCK_NEEDS_IF_HEADER: Shouldn't we be using an IF header to do an UNLOCK seeing as you need to prove you are holding a lock before you can remove it? (This might be contingent on LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY). Agreed that this was probably too late to change at this stage.

    - 68 UNLOCK_WITHOUT_GOOD_TOKEN -- should have preconditions for these, LD to check

    - 69 URL_ENCODING_ISSUES: We have to resolve some issues involving encoding methods for URI's. The discussion is very involved. -- HTTP URI issue

    - 70 LOCK_RENEWAL_SHOULD_NOT_USE_IF_HEADER: The LOCK renewal request should not us an IF header to specify what lock is being renewed. This limits the use of the IF header. Lisa thinks now well specified.

    - 71 IF_HEADER_CHECKS_AFTER_OTHER_CHECKS: Should we document if the IF header is evaluated before methods specific checks of afterwards. The IF header is said to be modeled after the IF-MATCH header and the documentation for that says that method specific checks should come first. It's not clear if it's feasible to make all method specific checks before checking the IF header. It's also probably easier to implement IF header checks at a common layer of code that is called before the method specific code in many implementations.


    Current issues list:


    The issue of whether bindings needs to explain how locks and bindings work together isn't listed there.

    What do we do with bindings? Options...

    1. last call as-is

    2. add more explicit text as requested

    3. delay until rfc2518bis is completed, then refer to bis for interactions

    4. extract locking out of rfc2518bis, refer to new locking draft for interactions

    Roy suggested to address only the real interoperability problems. Ted thought the draft needs clarification on some possible scenarios. Ted suggested that an explicit call to the mailing list seems necessary regarding whether we need clarifying text on the point mentioned (text already provided by LD on list).

    We noted there is precedent for splitting up a required feature out of a specification to a separate document: URLs were defined in HTTP in 2068, but out of HTTP in 2616 (2617 defined URLs). Larry said he didn't see how breaking the locking content into another draft will help. Joe said that if people think the bis draft us unclear, they should explain how.


    This was last updated to version -08 April 04. Open issues still exist. Julian proposes to defer work on this until after bindings is done. Brief discussion of whether we really need both redirect and bindings -- probably yes.


    This is a non WG doc that's ready for submission as a standard -- it's gotten significant review by HTTP WG, and significant support in WebDAV (implementors are out there waiting). Lisa applied for MIME registration for application/gdiff.

    We asked if we want to endorce this as reviewed by WEBDAV WG, or leave them be as individual drafts? We do want to put the question to list:

    do you plan to support this?


    draft-ietf-webdav-quota-03 -- is a WG item -- we will do WGLC call on this shortly


    Joe will discuss updated dates with authors. We may need volunteer