NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
Jim Whitehead <email@example.com>
Applications Area Director(s):
Keith Moore <firstname.lastname@example.org>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: Subject of subscribe
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 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 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:
*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
*Unprocessed source retrieval
*Informing proxies of an action's impact
*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.
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:
(Specification) Produce revised distributed authoring and versioning protocol specification. Submit as Internet Draft.
(Meeting, Specification, Requirements) Meet at Memphis IETF and hold working group meeting to review the protocol specification and requirements document.
(Scenarios) Revise scenarios document. Submit as Internet Draft.
(Scenarios) Create final scenarios document. Submit as Informational RFC.
(Requirements) Create final version of distributed authoring and versioning requirements document. Submit as Informational RFC.
(Specification) Produce revised distributed authoring and versioning protocol specification. Submit as Internet Draft.
(Specification) Complete revisions to distributed authoring and versioning specification. Submit as a Proposed Standard RFC.
· HTTP-based Distributed Content Editing Scenarios
· Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
· 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
No Request For Comments
Minutes of the WWW Distributed Authoring and Versioning (WEBDAV) Working Group
The WEBDAV working group met two times at the Washington IETF meeting, on Monday and Tuesday, December 8-9, 1997, and 78 people attended one or both of the sessions. The chair was Jim Whitehead, and notes were recorded by Alec Dun, Del Jensen, and Rohit Khare, then edited by Jim Whitehead.
I. DASL MINI-BOF
The Monday session began with a mini-BOF on the topic of WEBDAV searching and locating (DASL), led by Saveen Reddy. Saveen began by presenting slides on the goals of searching and locating:
· Efficient searching
· Properties & content
· Data model for resources
· Query languages
· Result set languages
· Simple and complex properties
· Effects on the HTTP + WebDAV protocol
- search criteria
- result set
- result record
- search scope
- boolean expressions: and, or, not
- relative comparators <, >, !=, <=, >=
- searches on content
- near operator
- result record definition
- standardization results format
- paged search results
· Search qualifiers
- scope: set of resources
- depth: recursion
- references: delegate the search
· Query language
- simple query syntax
- extensible syntax
- query syntax discovery
- access control
Attendees noted that there was overlap between the issues being considered by LESSOR and DASL, as well as between the searching in IMAP, LDAP, and ACAP and the searching proposed for DASL. Specifically, it was suggested that search comparators be leveraged from the Lessor group. Also, a note was made that reusing an existing search syntax would be a good idea. A thread of discussion investigated the interaction between DASL and LESSOR, asking whether they should have separate or overlapping spheres of work. There was a sentiment that DASL would be able to build upon the work of the LESSOR group.
Saveen gave information on how to become involved in the working group. The mailing list is email@example.com (send a message with subject "subscribe" to firstname.lastname@example.org), and the web page for the working group is http://www.ics.uci.edu/pub/ietf/dasl/.
Towards the end of the Monday session, a participant asked to see the proposed charter of the DASL working group. Unfortunately, although a proposed charter had been written, no slides were available with the proposed charter. During the Tuesday session, Saveen briefly presented the charter. The charter is also available via the DASL web page.
At the end of the mini-BOF, a straw poll of the attendees found substantial, but not unanimous, support for having a DASL working group in the IETF.
II. WEBDAV Working Group Meeting
After the DASL mini-BOF, the WEBDAV session began with a status report on the current documents being developed by the working group. Jim Whitehead led the discussion, and the slides he presented can be found at http://www.ics.uci.edu/pub/ietf/webdav/washington/jim/.
III. Document Status Review
Requirements: Approved as Informational RFC, RFC number is still pending. Many thanks to Judith Slein for her hard work on this document.
Distributed Authoring (DA) Protocol Specification: A schedule for completion of this document was presented. The chair announced that there will be a working group last call on this document in January.
ACL Requirements Draft, ACL Protocol Draft: WebDAV ACL issues are new, and not well understood. Active participation from the working group is strongly encouraged. Initial drafts of both documents are now available. Howard Palmer is the editor of the ACL Requirements, and Paul Leach and Yaron Goland are the editors of the ACL Protocol document.
Versioning Protocol Draft: Deferred to a later time (proposed schedule outlined). No objections voiced, but clarification asked for time frame. Several voiced concern that versioning be done in a timely manner.
Tree (recursive operations) Document: This draft has been merged into the DA protocol specification. No objections raised.
Scenarios Document: There was a call for volunteers to become editor of this document, and bring it to completion. Walter Houser volunteered.
IV. Ordered Collections
A discussion of open issues in the distributed authoring protocol specification took place during the remainder of the Monday session. Jim began by presenting slides summarizing the discussion on the mailing list. Functionality for ordered collections was discussed, with debate centering on what kind of ordered collection support should be provided, and whether the support should be mandatory given the processing burden on servers.
Why have support for ordered collections?
Larry Masinter: It's not that ordered collections makes products easier to build; it's that ordering is inherent, anytime there's export, for example, there needs to be a generic way to traverse it. Either of two protocols could work. BUT, if there's an order property, PROPFIND should return them in that order.
Yaron Goland: Ordering can be useful in some scenarios, sure. The key is, "should this feature be made mandatory?" As an implementor, most servers don't want to be saddled with this feature.
LM: BUT, when you do a PROPFIND, it has to come back in SOME order -- can't you expect to do a PROPFIND twice and get the same ordered response?
Paul Leach: I think you're making a *third* proposal: that there be some consistent ordering (e.g., alphabetical).
LM: are there any implementations where order will NOT be consistent? (YG: if it relates to disk defragmentation ordering...)
Someone: Shouldn't order be part of a query language, i.e., deferred to DASL?
PL: does sound reasonable.
YG: In a base WebDAV implementation, the client does sorting, storage into the order property; a DASL-enhanced one would do the sort on the server.
LM: There is some natural order; the natural way an implementation sends things back in a predictable way. BUT, if the ordering is not in the spec, clients can't rely on it; clients that don't know the server's BEST consistent ordering either have to spend time resorting it, or have the server sort oddly.
Alex Hopmann: there are two cases: (1) clients care about ordering or (2) client wants results returned in ordered fashion. We need to handle both cases and not preclude being able to get back in natural (fast) order.
A thread of discussion centered on whether the client should maintain the ordering (e.g., with an ordering property which it maintains), or whether the server should maintain the ordering.
Someone: It is easy to devise a scenario where the client or the server needs the resources in a specific order. These are both valid cases, so the protocol needs to provide a way to support both.
LM: The performance argument for ordered collections is that most underlying storage will maintain an order. If we don't provide a consistent natural order, then we will reduce performance because we will force clients to always do a search on a key. We don't enable a solution that works without requiring a search.
AH: If we have a consistent underlying order, what constraints based on adds/deletes do you make?
LM: There should be a property whose value is used to persist the order.
PL: So if I have 100,000 item property and delete an entry, do I have to reorder all the items?
LM: It doesn't matter, just remove that entry and you have a new order.
PL: This is very expensive, it will cost a lot to maintain this property properly. It's more complex than this.
Rob: We need three things, no order, client can request order, server can provide order.
Someone: I agree that collections should have a natural order. Does not matter on order (alpha, etc).
Paul: Slight correction, the natural ordering of a collection for any given replica of a collection (e.g., a collection in a replicated store) will vary from replica to replica.
No resolution was reached, discussion will continue on the list. There was much sentiment in favor of creating a separate document to address ordering, with some dissenters feeling the issue can be brought to a speedy close on the mailing list.
There was a final correction (by Larry Masinter) to the presented slides: The multipart/related MIME type is not ordered, however, the multipart/mixed MIME type is ordered. The multipart/alternative MIME type can be considered to be ordered by quality.
V. Security Considerations
Security considerations were discussed next, beginning with a slide presentation reviewing open security issues. Keith Moore noted that WebDAV should review the security considerations in the HTTP specification to ensure that no assumptions are broken when performing document authoring.
A participant raised the question: why won't the area directors go with Digest Authentication?
Keith Moore: (Thinking out loud) Hmmm. Digest Authentication might be acceptable since scaling isn't such an issue for authoring. I'm a little uneasy with the way passwords are handled on the server. Are all servers busted if a password is compromised on just one? (Paul responds 'No' to this. Keith continues.) Gee, why not go with Digest Authentication? Why don't you guys run this past Jeff Schiller. If he buys it, so will I.
The group reached agreement that a) the security considerations from HTTP/1.1 need to be reviewed to ensure they are unchanged for the domain of distributed authoring, b) WEBDAV will mandate use of digest authentication, c) for cases where greater security that an unencoded session is needed, use of TLS will be recommended.
VI. Index and Recursive Propfind
Finally, the working group agreed with the decisions of the Design Team that the INDEX method be removed in conjunction with adding recursive capability to PROPFIND, and the PATCH method be moved to the versioning specification.
VII. Access Control
Access Control was the topic of the Tuesday WEBDAV session. Howard Palmer led discussion on WEBDAV access control by presenting a series of slides highlighting design issues. These slides can be accessed at http://www.ics.uci.edu/pub/ietf/webdav/washington/acl/.
One thread discussed the problem of underlying repositories having access control schemes which vary (e.g., by operating system), the difficulty of mapping different schemes into each other, and the challenge this poses for WEBDAV access control. Since potentially many protocols can access the same resources (e.g., FTP and HTTP access to the same resource), perhaps access control is best addressed by a separate working group that considers cross-protocol access control. However, Nick Shelness pointed out that for other working groups that have addressed access control, the largest problems were how ACLs are granted or denied in a single overall model. Mark Day discouraged spinning off a separate group to address access control, opining that a WebDAV protocol without access control is not sufficient for authoring. There was no disagreement with this sentiment.
Nick Shelness: There are three options here: 1) don't address access control at all, 2) since authoring implies identity and AC specification, add that to the protocol, and 3) (the tar pit) is any form of prescriptive access control.
Scott Lawrence: You can't get away from: 1) the real access control is always going to trump DAV, 2) it will differ on different servers (by OS, etc), 3) reflection (acting on the AC protocol) is important.
A link-based proposal was discussed, where each resource has a link to an access control resource which contains an access control specification, which can vary across underlying storage repositories. This has the advantage that different underlying access control mechanisms can be easily accommodated. However, Yaron Goland raised concerns about this due to user interface complexity. For each access control scheme supported, there may need to be a separate user interface, and users find access control to be confusing as-is.
Finally, Paul Leach recounted an experience he had trying to map an access control list mechanism into the Unix access control mechanism supported by NFS. He found it to be very tricky mapping from one to the other, using an "impedance mismatch" analogy.
No consensus was reached (none was expected). Discussion on access control will continue on the mailing list.
DAV Searching and Locating
WebDAV Access Control Requirements
go to list