WEBDAV WORKING GROUP Meeting Minutes Washington, DC IETF December 8-9, 1997 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. 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 - Typing - Simple & complex properties - Effects on the HTTP + WebDAV protocol Requirements - terms: search criteria result set result record search scope - criteria: boolean expressions: and, or, not relative comparators <, >, !=, <=, >= searches on content variants near operator - results 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 - misc access control internationalization 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 www-webdav-dasl@w3.org (send a message with subject "subscribe" to www-webdav-dasl-request@w3.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, though 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. 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. This discussion was led by Jim Whitehead, and the slides he presented can be found at ht tp://www.ics.uci.edu/pub/ietf/webdav/washington/jim/. 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. 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 3 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. 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. 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. 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 which considers cross-protocol access control. However, Nick Shelness pointed out that for other working groups which 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.