RE: OPTIONS * (Was: RE: Comments on draft-dusseault-http-patch-00)

> That's because
> 
> - RFC2518 doesn't require it and
> - RFC2518bis has added it without any announcement whatsoever.

Ahh, here's our disconnect.  My assumption is that RFC2518 *does* 
require OPTIONS * to work, because RFC2518 requires that RFC2616
be implemented.  It's just one of many things that are part of 
WebDAV because they're part of HTTP/1.1.  It's my reading that support
of OPTIONS * is required for HTTP/1.1 therefore it was already 
required for WebDAV.  The addition to RFC2518bis was intended to
make obvious something that I thought implementors might not notice.


> How would an HTTP implementor outside the WebDAV working group even 
> *know* about that proposed change?

First, an HTTP implementor may not need to know about WebDAV changes.
Nothing in RFC2518 or RFC2518bis affects HTTP compliance or support.

Second, it's exactly by putting proposals into Internet-Drafts that
people outside a working group can most reliably learn about them.
Internet-Draft announcements are sent to a very broad list.  I myself
sometimes read Internet-Drafts for other working groups even if I'm 
not on the mailing list for that working group.

> > Whenever WebDAV defines OPTIONS headers or bodies, WebDAV needs
> > to define their behavior in OPTIONS * as well as OPTIONS 
> /specific/uri.
> 
> Fine. So please define that WebDAV doesn't put any additional 
> semantics 
> on OPTIONS *.

That's an interesting proposal.  How would you recommend doing that? 
Would the Allow header be incomplete?  Would the DAV: header be 
*missing* on a response to OPTIONS *?  Would DeltaV elements like
'DAV:version-history-collection-set' be illegal in the OPTIONS request
body if the Request-URI were '*'?  I fear this approach would break 
existing client implementations that do use OPTIONS * to detect 
server support.

It's a valid approach to say that WebDAV doesn't use, or doesn't
need, OPTIONS *.  However, I think that approach is less consistent, 
less compliant, and less interoperable with HTTP/1.1.  I still 
prefer for WebDAV to make clear that OPTIONS * support is required.
Then perhaps we'd eventually get out of our current situation of 
servers not supporting it properly, by having them add support.

Lisa

Received on Monday, 24 November 2003 15:39:15 UTC