NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Jim Whitehead <ejw@ics.uci.edu>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Keith Moore <moore+iesg@cs.utk.edu>
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/
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 that 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 users 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 previous work when it is applicable. Discussion of the security issues concerning distributed authoring and versioning are essential to the creation of a protocol that 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.
The final output of this working group is expected to be three documents:
A scenario 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. 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. 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:
Minutes of the WWW Distributed Authoring and Versioning (WEBDAV) Working Group
Reported by: Jim Whitehead
The WEBDAV Working Group held a meeting at the 38th IETF, in Memphis, TN, on April 7, 1997. There were approximately 50 people in attendance throughout the duration of the meeting. Jim Whitehead chaired the meeting, and Del Jensen collected minutes. Jim Whitehead reports these minutes due to the unavailability of Del Jensen for medical reasons.
The meeting began with a poll of the audience to determine how many people in attendance were familiar with the WEBDAV Working Group. Since approximately one third of those in attendance were being exposed to WEBDAV for the first time, the session began with a brief overview presentation on WEBDAV. This presentation was followed by a discussion, led by Judith Slein, on open issues in the requirements document.
During these first two presentations, questions were asked about the scope of the Working Group's activities with respect to security, authentication, and access control. The stated response, that WEBDAV was planning on using existing security and authentication schemes, but was not planning on implementing new schemes specifically for WEBDAV, met with some skepticism. Several parties expressed the opinion that distributed authoring in absence of good security, authentication, and access control was potentially dangerous, creating a hackers paradise. Another participant stated that expressing the WEBDAV requirements for security, authentication and access control was a necessary first step, even if the WEBDAV Working Group does end up using existing schemes for this functionality. One participant urged caution when considering these issues, stating that they were very complex (a.k.a., "pits of infinite depth"), while another viewed authentication and access control as server configuration issues, and hence out of scope for the Working Group. At the end of the discussion, Judith Slein took an action item to bring up a thread on the discussion about security, authentication, and access control.
Jim Whitehead next gave a presentation of several topics and preliminary proposals for their implementation, which were discussed in the Design Team meeting of April 1-4, 1997, held at U.C. Irvine, specifically locking, metadata, versioning, and partial write. Discussion of locking centered on a description of the characteristics of a proposed lock method, which can be used to provide two types of lock semantics: an exclusive write lock, where only the principal who owns the lock may modify the state of the resource (body and metadata), and a shared write lock, where only the principal(s) who own/share the lock may modify the state of the resource. There was some discussion about whether it should be possible to lock a deleted or non-existent resource in order to avoid a race condition between creating a resource (reserving its name) and then taking out a lock on the resource. This led to the need to define a new requirement to make it possible to reserve a name in the namespace controlled by a server.
Also discussed during locking was whether the proposed locking interface was sufficient for specifying a lock for replicated systems that employ a golden copy replication system. While the participants found no counter examples, one asked about non-golden copy systems. This raised the issue of whether locking capability should be a SHOULD requirement, rather than a MUST requirement, since non-golden copy replicated storage systems cannot implement a lock as defined.
Metadata facilities were described in terms of a "mixed" model, where small chunk metadata is expressed using attribute-value pairs stored with a resource, using new methods GETMETA, PUTMETA, DELMETA, and large chunk metadata is expressed using a link on the described resource which points to another resource which contains the metadata description. Referential integrity can be assured for small chunk metadata, but cannot be assured in the general case for large chunk metadata.
A proposal for versioning was introduced where instead of using special checkout and check-in methods, versioning would be performed using the lock, unlock, and a new "save" method which would update the predecessor and successor relationships and store an updated resource. A poll of participants found that they did not understand the new proposal well enough to tell whether it would work.
The old patch method was resurrected in the proposal for partial write capability that was presented. The notion of patch is that the body of the method request contains instructions for how to update the resource specified by the request URI. It was recommended that multipart/byte-ranges be used as the default update instruction format that must be supported in the patch method is supported. Some participants viewed this choice as strange. Other update formats suggested were VTML and Unix diff.