Current Meeting Report
Slides


2.1.15 WWW Distributed Authoring and Versioning (webdav)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 30-Jan-02
Chair(s):
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:
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.

NOT IN SCOPE:

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.

Deliverables

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.
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
RFC2518PSHTTP Extensions for Distributed Authoring -- WEBDAV

Current Meeting Report

 Minutes from WebDAV WG meeting
March 19, 2002
53rd IETF, Minneapolis
Reported by Larry Masinter, Adobe

Chair present: Lisa Dusseault, Xythos

Status of Various Efforts
-------------------------

DeltaV: The DeltaV working group is closed, however issues are still being discussed actively on the working group mailing list.
No interop events are planned as yet.

Q: Any clients for DeltaV? TeamStream (Xythos web file client) is a very limited client. Might assume that server vendors have clients. SubVersion has a client, but will only work with SubVersion for a while.

Interop Plans: WebDAV to Draft Standard requires demonstration of interoperability of various features between independent implementations. First interop was last August, another last fall, want to start again this spring.

Suggestion from Brotsky: schedule rolling, round-robin, server interops, e.g., server-client pair have dates for focus on interop issues. Match servers with clients every month. Some folks were interested.

Access control: in last call. Some discussion of special-purpose principal search reports.

DASL draft: Revived in WebDAV WG rather than defunct DASL WG. Julian Reschke planning 2 separate drafts. The framework draft will cover the model and the request/response syntax.
A separate mailing list exists for DASL, but some comments are mirrored on the WebDAV mailing list. Search framework issues:
character comparison, how to discover what search arbiter to search namespace portion, what are search arbiters? Not special resources.

Is any collection a potential search arbiter? Need for "more results" query.

Issue: there is some overlap of issues between DASL and XML Query.
However, XML Query doesn't handle marshalling, for example.
Coordination between DASL and XML is needed.
Query: member of XML Query working group will review DASL.

Individual drafts related to WebDAV:

- tickets (proposal to support tickets for access control by unnamed users)
- quota (proposal to expose 2 named properties to handle quota on collections: size and quota limit in bytes)
- property datatypes
Proposal to W3C to do XML element datatyping, predated XML schemas
- Ordering


Long list of dead drafts & proposals
either dead or sleeping
- bindings, redirect references, ordered collections, property registration proposal, property namespace and allprop, use of dublin core metadata in dav,
additional webdav ...
(take from slide)

comment: since drafts expire after 6 months, these proposals are dead unless re-raised.

Issue of differing use models driving WebDAV development in different directions
- use WebDAV as a file system.
- Use to work on local repository and publish/share to WebDAV.
- Synchronized use model, work on local store and sync, work from any machine, online or offline.
- Acrobat use webdav repositories for annotations when not for the documents themselves.
- Webdav for Web Site authoring and not for much for file sharing.

Some evidence: webdav getting more interest from PC users, increasing press. WebDAV tutorial at AIIM (document & content management folks).
Many document management tutorials. Article in PC magazine.

RFC 2518bis (potentially) closed issues
---------------------------------------

For moving to Draft, need two independent interoperable implementations of every feature: two clients & two servers for each feature.

Use and meaning of allprop? If allprop doesn't mean "all properties" what does it mean? Proposal: all properties defined in 2518 plus all dead properties client sets, but not live properties defined in other drafts. This has already been put into practice by servers, and that wasn't an issue at the interop event.

Who controls lock owner field? Client does. If a server-controlled field is needed, this will have to be done in a separate draft, not in RFC2518 bis.

When to refresh a lock timeout? Nobody implemented what the document said. New model: only a lock refresh request refreshes the lock.

Where root of repository may be? Some clients couldn't handle servers where path elements that aren't webdav resources.

Some servers couldn't do what some clients wanted. This has been clarified, in http://host/a/b/c/d, http://host/a/b might not be a webdav resource.

lock-null resources were removed from the spec. Most of the complex lock-null features weren't being used. A simpler model of creating a locked empty regular resource seems to be interoperable, it even work with clients that can lock unmapped URLs.

Removed propertybehavior feature.

Open issues in RFC2518bis
-------------------------

If header

Don't know what to do with the 'if' header.

Ambiguities in the specification lead to clients not implementing complex behavior. The syntax doesn't support multiline values, which could mean problems when large header values must appear all in one header.

E.g. IIS5 locks only resources, not collections, which results in many more locks in some situations. Operating on a collection containing many locked resources requires specifying different tagged lock tokens for each resource in If header. This results in such header length that web intermediaries cause problems.

How to apply with Depth and Destination headers?

"If" header confuses two purposes:
- conditional which clients requires to be met
- provision of lock token, which server requires to be there

Implementations seem to be more forgiving than spec suggests.
Can we demonstrate use or interoperability for
Tagged production? boolean combination logic support?
Use of ETags in "If" header?

Proposal: only use "if" header for a list of lock tokens.

Possible fix: add a header that does only one thing well, comma-delimited lock tokens?

Possible fix: describe current behavior of the if header, and leave it at that.

Dirk: If no-one is using the original if-header as originally specified: it's like there are two 'if' headers, maybe would allow existing syntax that clients use to be continue to be used, but in a more liberal way.

This is one of the thorniest issues.

Source Property

Another remaining issue: with the 'source' property. Have there been any implementations? (appears to be none)

Proposal: remove 'source' property

Those against this proposal (not present but their arguments were recapped) say that one can't use WebDAV for what it was originally intended to do, without source property

Those against this proposal fall into two camps.
1: source property is fine, we just need to put ourselves out to demonstrate interoperability.
2: source is not fine, let's use replacement that actually works

Does the source property actually works? One known problem with source property: 2518 doesn't define how to present and describe multiple sources

Brief discussion of using (Microsoft) Translate header. It's a boolean flag in a header. What it really means is "I'm in authoring mode" or "I'm in browsing mode". If header is missing, browser is assumed.

"Translate: F" when present asks for source rather than result. This is included in all authoring client requests.

Although Translate doesn't handle multiple source files directly either, it's possible that it addresses scenarios that are required to be addressed.

May have some advantages. For example, since it's present on all requests, the server can infer other preferences like 'PROPFIND returns size of original files'.

Slides

Agenda