RE: Marshalling DAV:xxx-collection-set as a live property, and not an OPTIONS request.

> Since I was not able to convince the ACL working group to marshall
> this kind of information as an OPTIONS request, we should probably
> consider changing the versioning protocol to also marshall this
> kind of information (i.e. DAV:workspace-collection-set,
> DAV:activity-collection-set, and DAV:version-history-collection-set)
> as live properties, and not as OPTIONS requests.

The big picture here is that we're making OPTIONS less useful. In
particular, we're saying that OPTIONS * is too hard for servers to
implement correctly with a bunch of extra headers and body information,
because * is too ambiguous.  That's probably fair enough; it's a result
of the early decision that not all resources on a HTTP server need be
WebDAV-capable resources.  Should we go so far as to say that clients
SHOULD NOT use OPTIONS *?

My concern with going in this direction is that a client accessing a
WebDAV server may be configured initially with only the server's domain
name. How does the client start figuring out what is where on the
server?  Does "OPTIONS /" + "PROPFIND /" (or the same requests to
whatever path is given) solve this problem for the client instead?  

If the client does OPTIONS only on particular resources, how *does* the
server show capabilities? E.g. support for MKCOL can *never* show up as
an allowed method on any existing resource.  My take is that MKCOL shows
up in OPTIONS * and not in any other OPTIONS request. Thus OPTIONS *
serves an important role.

Does the client need some way to ask the server "do you support WebDAV
anywhere on the server, and if so, where?"  This would be similar to the
question of asking a server "do you support HTTP on some port, and if
so, which"...

BTW, I'm curious what you mean by "changing the version protocol".  RFC
3253 can't be changed now. Are you proposing a new internet-draft to
eventually obsolete 3253?  Servers compliant with 3253 will continue to
be so even if the WG decides to replace OPTIONS marshalling with
property marshalling. I'm sure I'm stating the obvious, but I'm
surprised to see talk of changing DeltaV so recently after the RFC was
issued, particularly "for consistency" with documents that aren't yet
RFCs.

Lisa

Received on Sunday, 7 July 2002 20:37:24 UTC