NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-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:
· Extensions for Distributed Authoring and Versioning on the World Wide Web -- WEBDAV
· Requirements for Advanced Collection Functionality in WebDAV
· Requirements for Event Notification Protocol
Request For Comments:
RFC |
Status |
Title |
RFC2291 |
Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web |
Minutes of the WebDAV WG Meeting at IETF-42
The WebDAV working group held a meeting at the Chicago IETF on Thursday,
August 27, 1998, from 1PM to 3PM. There were 55 people in attendance. The
meeting was chaired by Jim Whitehead, and minutes were taken by John Stracke,
Stephen Martin, and Jim Davis.
Jim Davis presented on the Advanced Collections requirements document; his slides
are available at: http://www.ics.uci.edu/pub/ietf/webdav/chicago/ietf42acr.html
The Advanced Collections requirements document is currently in WG Last Call.
There were several issues raised concerning these requirements:
- There may be a requirement to be able to create a reference where the owner
designates the destination as not visible.
- Should there be a choice about whether deleting the target of a direct reference
also deletes all (direct) references.
- Should access control of references be distinct from those of the target.
- Should the owner of a resource should be able to prevent creation of references
to it using access control facilities? This would affect requirements for access
control, not advanced collections.
- Is there a need for references that pass some but not all operations.
- The documents need to be more clear on whether a reference is to a resources or
to a URI. Furthermore, the language defining a member of a collection is not very
precise in describing what a member is (Resource vs URI).
Jim Davis next presented on the Advanced Collections protocol document. Some
modifications to the protocol were discussed:
- Add a new property dav:references, which provides backpointers from a target to
all resources that refer to it.
- Redefine DAV's semantics for MOVE to insert a step between the COPY and the
DELETE. This inserted step, called UPDATE, updates any references to the
resource, if possible, changing the ref-target property to reflect the new location.
This resolves a conceptual issue of when referential updates are performed when
MOVE is defined as a COPY (which doesn't update references), followed by
a DELETE.
- Remove the "dav:passthrough" property, instead, just define a dav:reftype property
which takes either dav:direct or dav:indirect values. The rationale for this change is
the dav:passthrough property would have allowed client to create paradoxical
references, e.g. ones which pass through GET but not HEAD. For a useful direct
reference, there seems to be only one sensible set of values for what should be
passed through, and what not, namely: affect target: GET, HEAD, PUT, POST,
ROPFIND, PROPPATCH affect reference: DELREF, DELETE, COPY, or MOVE
except that the returned headers from GET and HEAD include extra headers
(Ref-Type and Ref-Target) added by the reference itself, which thus allow the
client to discover that the reference is a reference.
- A question was raised concerning whether a direct reference can point to a direct
ref? Yes. All the Ref-Type and Ref-Target headers are returned. This is sufficient
for the client to determine where the reference points to.
- Since the DELETE method deletes a reference no matter what type, there is no
need for the special DELREF method.
The ordered collections part of the document was skipped because Jim Davis ran out
of time. However, ordered collections were discussed at a breakout session on the
Advanced Collections Protocol, held in the afternoon on Wednesday, August 26.
Issues raised at this meeting concerning ordered collections:
- The LOCK method must also take headers for assigning initial position in ordering,
because a LOCK on a non-existent resource creates (at least temporarily) a new
member of a collection.
- Rename the dav:arbitary ordering value to dav:custom.
Some feel that the name dav:custom better reflects the meaning of a collection that is
ordered, but where the ordering is ad-hoc and known only to a human.
It allows for four possible conditions of ordering
1) Not supported on server. No orderingtype property.
2) Supported, but this collection is not ordered. dav:unordered
3) dav:custom
4) Some other URL
- Allowing the ORDERPATCH method to modify the position of more than one
resource at a time was discussed. Though objections to this were raised at the
Redmond meeting, noone at the breakout session could remember the rationale
for this objection.
Lisa Dusseault Lippert presented on Access Control Goals, and her slides are available at:
http://www.ics.uci.edu/pub/ietf/webdav/chicago/access_control/
Some discussion over the scope of this protocol: are we creating a mechanism to
manage underlying, pre-existing ACLs, or are we creating a mechanism to manage
DAV-specific ACLs? Consensus seems to be that the latter is the case.
Issues raised during the presentation are:
- Should ACLs apply to properties, and should properties have access rights scoped
to an individual property.
- Requirements should mention where and when the WebDAV access control facility
relates to access control faclilies of other protocols.
- It should be a goal of the protocol to have a simple interitance mechanism.
Dynamic vs static may not be necessary.
Chris Kaler presented results from the Raleigh meeting of the Versioning and Variant
Authoring design team. His slides are available online at:
http://www.ics.uci.edu/pub/ietf/webdav/chicago/versioning/
There was some discussion over why/whether versioning needs to support
downlevel clients.
Jim Whitehead opened discussion on whether we need to do configuration management
or not. Previously the WG said no; the versioning design team feels that versioning
without CM wouldn't be too useful, so we should do something simple, at least.
Consensus seemed to be that CM is going to be necessary for many customers, but a
burden for some others, so we should aim for a versioning protocol that can subset to
leave out the CM.
Versioning and Variant Authoring Design Team
DAV ACLs
WebDAV Advanced Collections Protocol