Alex Rousskov wrote:

> Given Jeff's comments, would it make any sense for those who need a
> working OPTIONS to specify their own extension method (e.g., FEATURES)
> and publish a small RFC instead of patching RFC 2616?

Possibly, but I don't think this applies to the questions that got us here.

WebDAV uses the DAV: response header in OPTIONS, and so far this seems 
to work just fine. The only disagreement that we have (had?) is whether 
clients can rely on "OPTIONS *" returning something meaningful. I think 
it has been shown that they can't, thus RFC2518bis shouldn't add any new 
language suggesting that. In addition, we have no evidence of clients 
that actually use that.

Regarding Lisa's draft for a PATCH method, I still believe that getting 
rid of any dependencies on OPTIONS will make it easier to be 
acccepted/implemented. At the very least it shouldn't require "OPTIONS 
*" to do anything it won't actually do in practice.

> ...
> Adding some extension header to OPTIONS, to signal new well-defined
> functionality would be a similar approach that does not require an
> extension method.

That's what WebDAV already does 
(<>), and 
besides the problem with "OPTIONS *", there doesn't seem to be any 
real-world problem with it.


<green/>bytes GmbH -- -- tel:+492512807760

Received on Tuesday, 25 November 2003 13:22:29 UTC