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
[email protected] (send a message with subject
"subscribe" to
[email protected]), 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.
