NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98
Chair(s):
Jim Whitehead <ejw@ics.uci.edu>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.Alvestrand@maxware.no>
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:
· HTTP-based Distributed Content Editing Scenarios
· Extensions for Distributed Authoring and Versioning on the World Wide Web -- WEBDAV
· WebDAV Tree Operations
· WebDAV ACL Protocol
· Requirements for Access Control within Distributed Authoring and Versioning Environments on the World Wide Web
· Requirements for Advanced Collection Functionality in WebDAV
Request For Comments:
RFC |
Status |
Title |
RFC2291 |
Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web | |
Minutes of the WWW Distributed Authoring and Versioning (webdav) Working Group
A WEBDAV WG meeting was held at the Los Angeles IETF, on April 2, 1998, with approximately 45 people in attendance. Jim Whitehead chaired the meeting, Rohit Khare, Del Jensen, and Jim Davis were notetakers. Final minutes were prepared by Jim Whitehead from these notes. The meeting began with a review of the agenda, followed by a presentation on WG status by Jim Whitehead. The WEBDAV Distributed Authoring Protocol document will be revised based on comments from the second working group last call, producing revision -08, and will be sent to the IESG for Last Call and review as soon as the -08 draft is in the Internet-Drafts directory. A WEBDAV interim working group meeting will take place June 15-17, 1998, in Redmond, WA, to discuss advanced collections functionality, versioning, and access control. Many thanks to Yaron Goland and Microsoft for hosting this meeting.
Following the WG status report, Keith Swenson, <kswenson@netscape.com>, <URL:http://people.netscape.com/kswenson/http_workflow>, gave a brief presentation on an HTTP-based workflow standardization effort that is just starting up. The purpose of this effort is develop an interoperability protocol for invoking and controlling an asynchronous process via HTTP. Elements of the protocol include simple process control (e.g., start, pause, resume), and the ability to start external systems, such as a backup process. A key element of the proposal is that it doesn't have to hold open a connection, since the initial design idea is to start a process, receiving in return an identifier URL for the process, which can then be used in subsequent operations. There will be an initial open meeting for
interested participants on May 4, 5, 1998, in Costa Mesa, California. The group's initial goal is to release a preliminary specification in six months.
After Keith's presentation, the question was asked, "How is this different from telnet?" The reply was this protocol does not require an open connection, and isn't intended to be a login-based protocol. The similarity between this work and IPP was noted, since IPP also uses HTTP, and isn't login-based. Following this question, there was brief discussion on the similarity between the notifications being discussed in IPP, PIPR, and the notifications being discussed for workflow support.
Jim Davis next led a discussion of the advanced collections requirements document, and this discussion lasted for the remainder of the session. The goals of the discussion were to generate shared understanding, and hopefully consensus on the requirements (goals), but not to do any design work. The presentation began with a review of terminology, then launched into a step by step overview of each requirement in the advanced collections requirements draft, draft-ietf-webdav-acreq-01.txt. The notes below are organized by requirement number.
A few questions were asked during the discussion which don't neatly fit underneath an existing requirement. These are:
Can one have a reference to a reference? Can a reference have more than one target (e.g., this might be useful in the context of content negotiation)?
Requirements-related discussion and outcome. Agreement represents the rough consensus of the attendees at the meeting, and this consensus is provisional pending discussion on the mailing list.
Requirements for Referential Collection Members:
3.1.1 The same resource may be referenced by referential members of multiple collections. Agreed.
3.1.2 The same resource may be referenced by more than one referential member of the same collection. Agreed.
3.1.3 It is possible for the same resource to be an internal member of a collection and also to be referenced by one or more referential members of that same collection. Agreed.
Requirement 3.1.3 sparked a discussion on circular references. Specifically, should WebDAV allow, disallow, or be silent about circular references? It was noted that a reference can point to any other resource, including a collection. Early WebDAV drafts do exempt servers from having to detect circular references.
3.1.4 Operations on a referential member do not affect the resource it references. Agreed.
Discussion of 3.1.4 led to one suggested new requirement:
N.1 Operations on a target do not affect the reference(s)
No consensus was recorded on this new requirement.
Requirement 3.1.4 also led to a discussion of preserving referential integrity of references. Participants asked whether deleting a referenced resource would result in deletion of the reference. Similarly for a move, would the reference be updated if its destination were moved? It was noted that in the general case, where the referred-to resource is on a different ver, maintaining referential integrity is impossible. However, some participants expressed a desire for a reference whose integrity would be guaranteed, even if that meant the server would limit the potential destinations of the reference. The two kinds of references were called "strong" (integrity-enforced) and "weak" (no integrity enforcement).
3.1.5 For any referential member of a collection, it is possible to obtain the URI of the resource it references. Agreed.
3.1.6 It is possible to add a referential member to a collection. Agreed.
3.1.7 It is possible to remove a referential member from a collection. Agreed.
3.1.8 It is possible for a referential member of a collection to carry its own properties, distinct from those of the resource it refers to. An example of this is the author, or "who added" property. Agreed.
3.1.9 A referential member of a collection also inherits the properties of the resource it refers to.
There was wide opposition to this, on the following grounds:
1. Assuming that the properties are copied when the reference is created, it is unclear what access rights to use when doing the PROPFIND. Documents and references have different access rights, and sometimes one is wider than the other.
2. After the properties are copied, the owner of the target resource no longer has means to control access on the properties.
3. ACAP has had problems with 'inheritance'.
4. Referential members are like symbolic links. But symbolic links do not in general have the 'properties' of their target. Their owner, size, and date modified all differ.
In addition:
4. If the properties are copied, they could be become out of date afterwards. In particular, one participant vehemently complained that inherit-by-lookup is out since it requires one server to track another.
Another participant raised the question: isn't this easily excisable -- since no other requirements build up on it, the minimum set of requirements could exclude it safely.
3.1.10 A listing of the members of a collection shows both the internal members and the referential members. Agreed.
3.1.11 Servers are encouraged to maintain referential integrity for referential members as far as possible, but are not required to do so.
No agreement. This requirement led to a re-opening of the integrity issues of 3.1.4. One participant noted that this requirement is like a "should" maintain integrity, but isn't should too weak to be useful? Some applications really care whether referential integrity will be maintained. The issue of cross-server integrity maintenance was raised, and what this implies for the scope of integrity maintenance. The discussion led to the following requirement:
N.2 It is possible to request creation of a referential member that the server will guarantee to have referentially integrity.
Some ideas on how this might be implemented were raised during the discussion, and include using a header to inform the server to create the reference only if it could guarantee the integrity. A property can be used to query the integrity maintenance capabilities of the reference.
There was agreement on this new requirement.
N.3 It is possible to discover whether or not a referential member has such 'integrity protection'.
Proposed, but no agreement reached. Needs discussion.
N.4 Is it possible to discover whether a resource is the target of such a 'protected referential member'.
Proposed, but no agreement reached. Needs discussion.
3.1.12 For any member of a collection, it is possible to discover whether it is an internal or a referential member.
Agreed.
Requirements for Ordered Collections:
3.2.1 The ordering mechanism is sufficiently standardized that different applications and servers can operate on the same ordering without private agreement.
Agreed, with change in wording: "Ordering is sufficiently standardized..." (i.e., remove "the" and "mechanism"), due to concern over the word 'mechanism', and its precise meaning and implications.
3.2.2 The semantics of an ordering are discoverable.
Agreed, but only after much discussion. There was general concern over the meaning of "ordering semantics", since it can be read pretty broadly. There was discussion of proposals to replace "semantics" with "operational characteristics" or with "ordering methodology", but in the end the original wording prevailed. However, an action item was recorded to discuss the meaning of "ordering semantics" on the list.
3.2.3 When a client requests a listing of the members of a collection, it can specify the ordering to be applied, and the server will apply that ordering to its response.
Agreed, with the addition that "The server may decline to support the requested ordering".
3.2.4 It is possible to order the members of a collection in an arbitrary way, not necessarily based on property values.
Agreed, with the word "arbitrary" changed to "client-specified". One way we got into trouble here is that since the ordering might well be stored in a property, it's hard to think of an ordering that is NOT based on a property value. Also, there was much sentiment that DASL should support sorting on property values, and that orderings based on property values alone should be left to DASL and not addressed here.
There were some dissenting comments that noted that this feature should be optional, and not required. Also, some parts of a server may not be able to support ordering.
3.2.5 Internal and referential members may by intermixed in the same ordering. Agreed.
3.2.6 It is possible to impose multiple orderings on the same collection.
No agreement. No one at the meeting was able to propose a scenario that actually requires more than one ordering. The scenario in the requirements document was discredited, on the claim that the two instructors should instead each create their own collections, using referential members, and impose the ordering they wished.
There was general agreement with a proposal to remove 3.2.6. As a result of this change, 3.2.4 becomes a labeling issue, and there was strong sentiment that 3.2.3 and 3.2.7 should be removed as well, since this preserves a model where there are collections with preserved order and DASL capability for sorting. Furthermore, there was some discussion about whether 3.2.8 should also be removed.
3.2.7 An ordering is not required to contain all members of the collection.
No agreement, for the same reasons discussed in 3.2.6.
3.2.8 A collection member may belong to the same ordering more than once.
No agreement, for the same reasons discussed in 3.2.6.
3.2.9 It is possible to modify an existing ordering efficiently.
No agreement. One participant noted that this seemed strange, since it's like a "motherhood" statement.
There was significant participant uncertainty from the discussion of 3.2.6 until the end of the session.
There was insufficient time to discuss the "Issues" from the advanced collections requirements draft.
Meeting Adjourned
None Received