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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 24 Nov 2003 20:24:58 +0100
Message-ID: <3FC25B0A.7020104@gmx.de>
To: Helge Hess <helge.hess@opengroupware.org>
Cc: 'Webdav WG' <w3c-dist-auth@w3c.org>

Helge Hess wrote:

> On 24.11.2003, at 19:50, Julian Reschke wrote:
>> However I feel it entirely unacceptable to add new "must" level 
>> requirements (RFC2518bis, section 9.1) when
> ...
>> b) it clearly is impossible to implement for a generic Java servlet.
> Hm, this comment is *really* weird. A generic HTTP API is restricted 
> because some API which isn't nearly as old as HTTP doesn't provide the 
> required functionality?

No, it's not weird at all. When we discuss RFC2518bis, we are talking 
about progressing RFC2518 from "proposed" to "draft". Usually, this 
precludes adding any new requirements, unless there is already proven 

As a matter of fact, many of the currently existing WebDAV server 
implementations are based on the servlet API, and thus -- by defintion 
-- can't comply to the new requirement.

In addition, I have some very strong feelings (:-) about adding new 
"must" level requirements to a spec revision without

- any prior discussion (or even consensus)
- any clear benefit
- or even any notice to the working group (such as announcing the change 
after the Internet Draft was submitted)

Speaking about the PATCH method proposal - this is something new that 
doesn't need to be compatible with any existing implementation. However, 
I feel that putting additional requirements on OPTIONS is a bad idea

- because it will harm implementability in servlets and
- it introduces a dependency on other HTTP methods that doesn't seem to 
be necessary.

Finally, adding "must" level requirements to a spec that are likely to 
be ignored by many servers is really a disservice to everybody. Either 
people won't implement the spec at all, or they will and will claim 
conformance, although their implementation doesn't fully comply. In the 
latter case clients that rely on that behaviour (being a "must") will 
run into problems (in the best case, they'll not be able to use that 
feature although it's there).

Regards, Julian

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 24 November 2003 14:25:25 UTC

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