2.1.13 WWW Distributed Authoring and Versioning (webdav)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

Jim Whitehead <ejw@ics.uci.edu>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

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:

This working group will define the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs.

The HTTP protocol contains functionality which enables the editing of web content at a remote location, without direct access to the storage media via an operating system. This capability is exploited by several existing HTML distributed authoring tools, and by a growing number of mainstream applications (e.g. word processors) which allow users to write (publish) their work to an HTTP server. To date, experience from the HTML authoring tools has shown they are unable to meet their user's needs using the facilities of the HTTP protocol. The consequence of this is 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.

An ad-hoc group has analyzed the functional needs of several organizations, and has developed requirements for distributed authoring and versioning. These requirements encompass the following capabilities, which shall be considered by this working group:

IN-SCOPE:

*Locking: lock, lock status, unlock

*Name space manipulation: copy, move/rename, resource redirection (e.g. 3xx response codes)

*Containers: creation, access, modification, container-specific semantics

*Attributes: creation, access, modification, query, naming

*Notification of intent to edit: reserve, reservation status, release reservation

*Use of existing authentication schemes

*Access control

*Unprocessed source retrieval

*Informing proxies of an action's impact

*Versioning:

*Checkin/Checkout

*History graph

*Differencing

*Automatic Merging

*Naming and accessing resource versions

Further information on these requirements can be found in the document, "Requirements for Distributed Authoring and Versioning on the World Wide Web". <http://www.ics.uci.edu/~ejw/authoring/webdav-req-00.html

While the scope of activity of this working group may seem rather broad, in fact much of the functionality under consideration is well understood, and has been previously considered. This working group will leverage off of previous work when it is applicable. Discussion of the security issues concerning distributed authoring and versioning are essential to the creation of a protocol which implements this functionality.

Though the feature set described above bears a resemblance to the capabilities provided by a network file system, the intent of this working group is not to create a replacement distributed file system (e.g. NFS, CIFS). The WEBDAV emphasis on collaborative authoring of resources which are not necessarily stored in a file system, and which have associated metadata in the form of links and attributes, differentiate WEBDAV from a distributed file system.

Many decisions have been made to reduce the scope of effort of this working group. It is the intent of this working group to avoid the inclusion of the following functionality, unless it proves impossible to create a useful set of distributed authoring capabilities without it:

NOT IN SCOPE:

*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 non-HTTP protocols (except email)

*Implementation of functionality by non-origin proxies

Eventually, it is desirable to provide access to WEBDAV capability by disconnected clients, or by clients whose only connectivity is via email. However, given the scope of developing requirements and specifications for disconnected operation, the initial target user group of fully connected clients, and the desire to work swiftly, the working group will address this issue by ensuring the protocol specification does not preclude a future body from developing an interoperability specification for disconnected operation via email.

Deliverables

The final output of this working group is expected to be three documents:

1. A scenarios document, which gives a series of short descriptions of how distributed authoring and versioning functionality can be used, typically from an end-user perspective. Ora Lassila, Nokia, currently visiting with the World Wide Web Consortium, is editor of this document.

2. A requirements document, which describes the high-level functional requirements for distributed authoring and versioning, including rationale. Judith Slein, Xerox, is editor of this document.

3. A protocol specification, which describes new HTTP methods, headers, request bodies, and response bodies, to implement the distributed authoring and versioning requirements. Del Jensen, Novell, is editor of this document.

The most recent versions of these documents are accessible via links from the WEBDAV Web page.

Goals and Milestones:

Mar 97

  

(Specification) Produce revised distributed authoring and versioning protocol specification. Submit as Internet Draft.

Apr 97

  

(Meeting, Specification, Requirements) Meet at Memphis IETF and hold working group meeting to review the protocol specification and requirements document.

Apr 97

  

(Scenarios) Revise scenarios document. Submit as Internet Draft.

Aug 97

  

(Scenarios) Create final scenarios document. Submit as Informational RFC.

Aug 97

  

(Requirements) Create final version of distributed authoring and versioning requirements document. Submit as Informational RFC.

Aug 97

  

(Specification) Produce revised distributed authoring and versioning protocol specification. Submit as Internet Draft.

Dec 97

  

(Specification) Complete revisions to distributed authoring and versioning specification. Submit as a Proposed Standard RFC.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2291

  

Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web

Current Meeting Report

WEBDAV WORKING GROUP

Meeting Minutes
IETF-43, Orlando, Florida
December 10, 1998

The WebDAV WG met on Thursday, December 10, 1998, from 1300-1500, with 42 people in attendance. The meeting was chaired by Jim Whitehead, and meeting notes were recorded by Rohit Khare. Final minutes were prepared by Jim Whitehead.

Three main topics were discussed: advanced collections goals and protocol (<draft-ietf-webdav-collection-protocol-02> and <draft-ietf-webdav-collection-reqts-03>), versioning (<draft-ietf-webdav-versioning-00>), and issues from the distributed authoring protocol (<draft-ietf-webdav-protocol-10>). There was a brief discussion at the end of the meeting on additional properties (draft was not submitted in time for the meeting). Prior to the main meeting, two informal breakout sessions were held on the topics of Access Control and Advanced Collections.

Jim Whitehead began the meeting with an agenda overview. He also announced that the WebDAV Distributed Authoring protocol specification was approved as a Proposed Standard by the IESG on November 25, 1998.

ADVANCED COLLECTIONS:

Judith Slein led discussion on Advanced Collections, discussing the issues:
- What mechanism should be used to disable the referential capabilities of reference resources
- Optional backpointers
- Should it be possible to hide the target of a direct reference
- Enforcement of referential integrity

Judith announced that Jim Davis's sandbox.xerox.com test server on 8080 has redirect and direct references working according to the current protocol specification, <draft-ietf-webdav-collection-protocol-02>.

** What mechanism should be used to disable the referential capabilities of reference resources:

Judith described a proposal from the advanced collections brekout session to have a header, tentatively called "No-Passthrough", which would disable the passing-through of method invocations to the target of a direct reference, and the issuance of a 302 for a redirect reference.

There was discussion on what happens if you send a No-Passthrough header to a resource that's a hardcoded redirect -- a 302 from the server/CGI-script; rather than being a 'redirected reference'. In this case, a client might find it difficult to disambiguate between the hardcoded 302, and a redirect reference. Due to this, a client might expect the hardcoded 302 to respect the semantics of the No-Passthough header, operating on the false idea that the hardcoded 302 was actually a redirect resource. The hardcoded 302 (especially those from a downlevel CGI script) would very likely not respect the semantics of the No-Passthrough header. One possible solution is to use the proposed Mandatory header (the Mandatory header lists other headers which MUST be understood, or the method invocation fails). It was unclear how this would address the downlevel CGI script case, which would presumably not understand the Mandatory header either. It was noted that a client can tell whether the 302 redirect it receives is a 'normal' (hardcoded) 302, or a 302 from a redirect resource, since the 302 response message from a redirect resource must contain the Ref-Type header. This allows a WebDAV-aware client to know what kind of resource is causing the 302 response.

It was noted that the proposed No-Passthrough header needs to be clear about the effect of the No-Passthrough header on non-redirect references.

A working group member noted that we should be more precise about reference vs resource: in some sense, every URI is a redirect to an actual resource.

This issue will be taken to the list for further discussion.

** Optional backpointers:

Several working group members had problems with the optional backpointers proposal. One noted that if clients can't depend on the backpointer property being there, and even if it is there, users can't be sure what it means since there is no guarantee it contains all backpointer references (since some references to this resource might be located on other servers, hence outside the realm of control of the server managing the resource which has the backpointer property). Hence, this is not the business of DAV or a DAV client; this is what (server-specific) live properties are for.

It was noted that if backpointers are an arbitrary property, there won't be as much interoperabilty. This was countered by noting there isn't any interoperability in this scenario to begin with, due to the fact the property might not be present, and might not contain all possible backpointers.

One working group member suggested that the original rationale for having backpointers was to use them as a mechanism for navigating to the parents of a resource, especially when the containing collection includes members which are not lexically/syntactically related to the URL of the collection. However, working group members disagreed with this.

There was a suggestion that if anyone is going to provide backpointer capability, it is important that we reserve a property name which *will* be used for this, or preserve a name which is reserved for future use. There no support for this idea. As another working group member noted, there is no point to having standardized properties in this case. If the property is optional and server-specific, it can be interoperable and it can be handled in a separate draft at later time and go to Proposed separately.

There was another suggestion to establish some principles about what are the responsibilities of the client, the server, and the repository.

Discussion of optional backpointers will be taken to the list.

** Should it be possible to hide the target of a direct reference:

There was brief discussion on whether it should be possible to hide the target of a direct reference. One working group member seconded the idea that this be handled as a security right, and not handled in the advanced collections protocol.

** Enforcement of referential integrity:

Discussion on referential integrity began by noting the following scenario. At creation time, it should be possible to suspend referential integrity. This would allow you to create a template collection of pointers and realize the contents later.

One working group member moved to strike all mention and discussion of referential integrity. However, another working group member noted that their configuration management product does support strong and weak references, and they will expose it on our own if not standardized. They would like to have interoperabilty with other configuration management vendors. Another member noted that in their document management system, they initially tried to enforce integrity at the front end, but now the just warn the user, and do not provide any back-end integrity.

Judith stated that she will start weekly phone calls on Adv. Collections to bring these issues to resolution. Jim, as chair, stated that these discussions have been proceeding for too long and he's looking for progress or hatchets.

VERSIONING:

Geoff Clemm led discussion on versioning. He announced that a versioning goals document will appear soon. During the meeting these issues were discussed:
- Data model for a versioned resource
- Are checked-in resources mutable or immutable
- Semantics of checkout
- Use of lock as a mechanism for checkout

** Data model for a versioned resource:

Geoff presented from hand-written slides. His presentation was on the data model of a versioned resource, and differed slightly from the data model discussed at the versioning and variant authoring design team meeting held a week before the IETF meeting.

Geoff's presentation, paraphrased in sentences is:

There is a resource under version control. A versioned resource is a set of (or potentially a collection of) working resources. A working resource supports the CHECKOUT operation, which returns a new working resource. A working resource supports a LABEL, which is a reference to another working resource, which may take the value of "stable", "current", "mine", etc. A working resource also supports the CHECKIN operation, which creates an immutable revision. A configuration has a selection rule (perhaps an XML description) to describe a configuration of working resources.

Working group discussion ensued.

A concern was raised about server limits. Does the server have to provide storage space for lots of client checkouts? What are the risks associated with rogue clients -- could versioning be used as a form of denial of service attack? Geoff stated that there is an implicit put/creation of working resources. But, the working resource does not have to live on the same server -- it could live in the client until checked in.

** Are checked-in resources mutable or immutable:

There was some discussion on terminology. One member asked about the difference between a working resource, revisions, and resources. Answer: there is a set of working resources associated to every versioned resource. Mutability is the base case; immutable checked-in revisions are layered on top. A revision is an immutable working resource. Checking out a working resource to create a new working resource takes a snapshot of the contents.

A concern was raised with this approach. The advantage of thinking of revisions and revisions-which-can-be-thawed (the revisions-which-can-be-thawed approach was discussed at the design team meeting -- in this approach, a checked-in resource may be edited if it supports the THAW method, and the client invokes THAW on the checked-in resource) is that a versioning client would do a checkout, perform their edits, then checkin. There is a tradeoff between client and server complexity. Having resources be immutable by default, with a thaw operation used to edit checked-in resources, would allow a client to use the same interaction style for all versioned resources (checkout, edit, checkin); now, it would need to do some repository discovery to see whether it needs to perform a checkin operation. It was noted that if you only have mutabilty, the client can employ a checkout-only protocol. Another member noted that they have scalability concerns -- for their system, a checkout is a mutex operation, and no one else can branch or checkin from there.

** Use of lock as a mechanism for checkout:

There was a discussion on use of the LOCK method for performing checkout/checkin capability, perhaps with a versioning lock. Arguments in favor of this approach are the ability to reuse an existing method, rather than creating new methods, which is asserted to be more simple for clients to support, especially clients which understand WebDAV, but do not understand the versioning extensions. There was concern that we are not accomodating the simplest kinds of clients. It was noted that it is an explicit goal of the versioning design team to accomodate "automatic versioning", or versioning for HTTP/1.1 or WebDAV aware, but versioning unaware clients.

The following locking capabilities are needed:
1) Locking a versioned resource as a whole.
2) Locking a particular working resource.
3) Locking an entire branch (for branch-based CM)

Arguments against using LOCK for checkout and checkin operations:
1) Separation of concerns: the protocol is more simple by leaving locking alone.
2) Locking is optional and hence cannot be depended upon to be present.
3) When the design team explored using lock, the resulting protocol was complex, and added a lot of new headers.
4) The lock approach does not scale up to handling configuration management.
5) If all you want is temporary ability to write-protect, lock it; if you want it PERMANENTLY write protected, another operation needs to be used.

One working group member noted that there are certain versioning clients that would be very displeased if revisions were mutable. However, they suspect that most clients wouldn't care, and would prefer the freeze-thaw approach vs. checkin/checkout approach.

Another member wanted a clarification of mutable vs. immutable. They wondered whether immutable means the bit-pattern is fixed for all time, or that administrators still have root-like priviliges. The sense of the working group was that they mean the former (bit pattern is fixed for all time). Clients must be able to depend on caching and repeatability of configurations.

Another working group member noted that HTTP has strong and weak e-tags (bit-by-bit equality or usable-equivalent, respectively). It would make some sense to support these semantics in the web authoring protocol.

ISSUES FROM LIST DISCUSSION:

Jim Whitehead next led discussion on issues from the discussion list. Issues discussed were:
- Issues for revising the document going to Draft Standard
- Disambiguating between URI and URL
- Storing attributes submitted in XML properties
- Namespace consistency

** Issues for revising the document going to Draft Standard:

One working group member asked for formal interoperabilty testing and continued tuning of the drafts as they progress from Proposed to Draft Standard. Jim Whitehead stated that he is working on an HTTP WG-style issues list, and sees this as his responsibilty as chair.

Jim also suggested that, based on email he has received, a mailing list specifically for implementors seems to be a good idea. Working group members disagreed: in other groups, it's been strongly suggested that reports from implementors should be kept on the main list. Implementors will be encouraged to submit their interoperability reports to the main list.

Another working group member suggested that the WebDAV working group should develop a canonical test suite. There was a lot of disagreement -- the IETF does not perform branding. There was a suggestion to spin out the branding to another organization.

Jim Whitehead stated that he is in the planning stages for an interoperability event in Feb/Mar 99.

Another working group member noted that client testing has its own special set of concerns, and can be more difficult than server testing. Client testing takes lots of instrumentation, and may introduce bugs into the client. The HTTP model worked well, using the bakeoff model with feature-by-feature pairwise testing. Furthermore, it is an IETF requirement to perform feature-by-feature tracking to advance to Draft Standard.

** Disambiguating between URI and URL:

It is believed that draft-ietf-webdav-protocol-10 now correctly disambiguates between URI and URL, and uses them correctly. Larry Masinter noted that if you could find an implementation detail which actually disambiguates URI vs URL, he would be very surprised indeed.

** Storing attributes submitted in XML properties:

The specification is currently silent on the topic on what a server is required to do with XML attributes submitted as part of a PROPPATCH "add" request. One working group member expressed quite strongly that he feels the specification IS clear, that any XML element -- which includes attributes, must be stored. Yaron Goland stated that the spec was intended to be silent, as a compromise. Another member argued for storing the entire element, especially since there *are* legitimate uses of XML attributes. However, some repositories would have to be changed to accomodate storage of XML attributes. Yaron Goland stated that WebDAV uses XML as a transport format, not for its object model. The use of attributes was not required. Another member noted that we should not define our own variant of XML for use in properties.

This issue will be taken to the list for more discussion.

** Namespace consistency:

One member noted that it is hard, on the face of it, to identify the benefits of the namespace consistency requirements in draft-ietf-webdav-protocol-10. The server has to work harder; what efficiencies do clients rely on? Others noted that without consistency, our collection semantics fail. This was rebutted: how does *that* help? What is the utility of requiring namespace consistency of collections? It was noted that some rationale was provided on the list.

This discussion is being taken to the list.

COLLECTION PROPERTIES:

Lisa Lippert led a very brief discussion on a proposal that was not submitted as an Internet-Draft before the Orlando IETF submission deadline.

The proposal is to have a set of optional properties on collections, these properties being:

hassubs / nosubs - Does the collection have collections as children?
childcount - The number of members of the collection reserved
ishidden - Is the resource hidden (like a "." file in Unix)
id
visiblecount - The number of visible members
defaultdocument
isfolder
isstructureddocument - The collection is modeling a compound document
objectcount

There was some concern over whether these properties were already implemented. The specter of "infinite implementation complexity" was raised.

One member raised the issue of having an IANA registry of properties.

*** Meeting Adjourned ***

Slides

None received.