W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2003

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

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 24 Nov 2003 12:13:36 -0800
To: "'Julian Reschke'" <julian.reschke@gmx.de>
Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <007c01c3b2c7$713a2d60$75c990c6@lisalap>

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

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

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

Received on Monday, 24 November 2003 15:13:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC