W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

Re: draft-reschke-http-addmember-00

From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Date: Tue, 22 Feb 2005 10:38:04 -0800
Message-Id: <200502221838.j1MIc451030030@wera.hpl.hp.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>, WebDAV <w3c-dist-auth@w3.org>

Jamie Lokier writes:

    For example, some URLs will treat any method as form submission, even
    OPTIONS, so users should never ask a client which uses OPTIONS to
    access those URLs, because that is dangerous.
    
Let's be VERY careful about statements like this.  If Jamie means
his "should" in a normative sense, then this is flat-out wrong.

RFC2616, section 9.1.2, says:

   ... the methods OPTIONS and TRACE SHOULD NOT have side effects, ...

and section 9.2 says:

   [The OPTIONS] method allows the client to
   determine the options and/or requirements associated with a resource,
   or the capabilities of a server, without implying a resource action
   or initiating a resource retrieval.

So any implementation of HTTP (including either a server per se,
or its ancillary software!) that "treats any method as a form
submission" is manifestly non-compliant with the specification.

It is essentially impossible to specify a protocol, let alone
evolve it in a compatible way, if one cannot assume that
implementations are minimally compliant.  (Some might quibble
that the "SHOULD" in 9.1.2 gives stupid implementors some cover,
but the distinction between "SHOULD" and "MUST" in RFC2119
doesn't apply to stupid implementors.)  Without the assumption of
compliant implementations, there really is no point in even
trying to write specifications.

If Jamie is arguing that we need to add new method because
implementations are not compliant with the specs for the old
methods, that seems to be a recipe for doom.  (RFC2616 is already
encrusted with some features that were designed to get around the
fact that, prior to RFC2068, there was no formally accepted
"specification" for HTTP at all; these are the most ugly parts of
RFC2616.)

There might be other, more plausible arguments for ADDMEMBER
(although in this case, I agree fully with Roy: I haven't seen a
successful argument made yet).  But this argument against using
OPTIONS cannot be one of them.

-Jeff
Received on Tuesday, 22 February 2005 18:38:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:39 GMT