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

Lisa Dusseault wrote:

>>"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)."
> 
> 
> This paragraph specifically *does* say that the client can test
> the capabilities of the server.  How are the RFC2518bis or PATCH 
> proposals in opposition to this?

I guess it depends on the definition of the server. Fact is

- the servlet spec doesn't support that in general,
- it doesn't seem to be supported by Apache modules (OPTIONS * on 
http://test.webdav.org doesn't list any WebDAV methods) and
- it doesn't seem to work with IIS (just tried and I got a 404).

So as far as RFC2518 is concerned, there is demonstratibly *no* 
interoperability for this, and I never have heard of any client 
requiring it. Therefore it doesn't belong into RFC2518bis.

>>However I feel it entirely unacceptable to add new "must" level 
>>requirements (RFC2518bis, section 9.1) when
>>
>>a) this contradicts RFC2616 and
>>b) it clearly is impossible to implement for a generic Java servlet.
>>
>>If you feel strongly about adding this to WebDAV, please discuss it 
>>first. However just silently putting it in without any prior 
>>discussion 
>>IMHO really isn't constructive.
> 
> 
> As you know by my disagreement, I don't see how this contradicts 
> 2616.  So I'm not trying to add this particular functionality to 
> contradict 2616.   I've also pointed out that it's not impossible 
> for an application that uses Java servlets, so I'm also not trying 
> to break those applications.

It's impossible for a web application that is deployed on a standard 
servlet engine, unless it's mapped to the root (and the WebDAV WG has 
already stated that it's perfectly legal to have a WebDAV server 
implementation that doesn't control the whole namespace of a particular 
HTTP host).

> As for discussion, we *are* discussing.  I-D documents *are* what
> we discuss.  The IETF process is to submit proposals, that not everybody
> may agree with, as I-Ds.  These are discussed and frequently change as
> a result.  By the very act of publishing an Internet-Draft, I am being
> anything but silent about suggested text, possible solutions, proposals,
> and so on.
> 
> I appreciate your attempts to help gain consensus.  It is my opinion,
> and supported by IETF practice in many working groups and by RFC 3160,
> (The Tao of IETF) that publishing I-Ds with specific new proposals to 
> discuss is a useful way to achieve consensus:
> 
> "Internet Drafts are tentative documents -- they're meant for readers 
> to comment on, so authors can mull over those comments and decide which 
> ones to incorporate in the draft."

Yes. I just wish it would be easier to do that for RFC2518bis. 
Up-to-date issues/change lists would really help. The only way to spot 
this change is indeed to diff the TXT versions of the internet drafts. 
Does it really have to be that hard???

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

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