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

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Monday, July 08, 2002 2:36 AM
> To: Clemm, Geoff; DeltaV (E-mail)
> Subject: 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 *?

I think the main issue is that this is a usage of OPTIONS that doesn't seem
to be in line with HTTP 1.1, which says:

"If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to
apply to the server in general rather than to a specific resource. Since a
server's communication options typically depend on the resource, the "*"
request is only useful as a "ping" or "no-op" type of method; it does
nothing beyond allowing the client to test the capabilities of the server.
For example, this can be used to test a proxy for HTTP/1.1 compliance (or
lack thereof)."

Consequently, the servlet API doesn't offer my any simple mechanism to
influence the result of "OPTIONS *" (or am I missing something).

So the feature is under discussion because it's extremely hard if not
impossible to implement, and thus will be questioned once when RFC3253 takes
the next RFC standardization step.

> 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

I think that's a configuration a bug. If only part of the URL namespace on a
server talks WebDAV, you'll need the URL prefix of this namespace partition.
There's no way to avoid that right now.

> server?  Does "OPTIONS /" + "PROPFIND /" (or the same requests to
> whatever path is given) solve this problem for the client instead?

No.

> 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.

...would serve an important role, if it could be implemented. If you think
that discovery of MKCOL using "OPTIONS *" is an important feature, we should
find out whether there are interoperable implementations supporting that.

HTTP 1.1 clearly states that if you do OPTIONS * and look at the allowed
methods, you CAN NOT take the absence of MKCOL (in Allow:) as sign that no
part of the URL namespace supports this method. If your client assumes that,
it's buggy.

> 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"...

I'm not sure why a client would need that. If the WebDAV-enabled namespace
doesn't start at "/", the client will have to be configured to know the
complete prefix. To change this, the process implementing the root resource
will need to have knowledge of all other descendants in it's namespace, and
a *new* protocol is needed to marshall this information.

> 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

The RFC can't be changed, but the protocol can (in the future).

> eventually obsolete 3253?  Servers compliant with 3253 will continue to

My take is that with RFC3253, we should try to get the next revision
(proposed -> draft) out as soon as we have multiple interoperable
implementations. So it absolutely makes sense to discuss these issues right
now rather than waiting too long (as it happened with RFC2518).

> 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.

But then, what's the point in delaying this work? The sooner an issue is
discussed, the earlier we can add it to the errata document (preferrably
with a resolution of the issue). We all benefit from that: the WG, because
things get resolved when they are raised (instead of years later), and
implementors (because they can use *both* RFC3253 and a draft of a deltaV
revision) to implement their servers.

Received on Monday, 8 July 2002 04:16:18 UTC