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.