[Ietf-caldav] Re: draft-reschke-http-addmember-00

Jeffrey Mogul <Jeff.Mogul@hp.com> Tue, 22 February 2005 18:38 UTC

X-Envelope-From: Jeff.Mogul@hp.com
X-Envelope-To: <ietf-caldav@osafoundation.org>
Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1MIc7aa029823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <ietf-caldav@osafoundation.org>; Tue, 22 Feb 2005 10:38:07 -0800
Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by palrel11.hp.com (Postfix) with ESMTP id 20B51F03A; Tue, 22 Feb 2005 10:38:07 -0800 (PST)
Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by hplms2.hpl.hp.com (8.13.1/8.13.1/HPL-PA Hub) with ESMTP id j1MIc571022842; Tue, 22 Feb 2005 10:38:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.10/8.12.9) with SMTP id j1MIc451030030; Tue, 22 Feb 2005 10:38:04 -0800 (PST)
From: Jeffrey Mogul <Jeff.Mogul@hp.com>
Message-Id: <200502221838.j1MIc451030030@wera.hpl.hp.com>
X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol
To: Jamie Lokier <jamie@shareable.org>
In-reply-to: Your message of "Tue, 22 Feb 2005 16:15:21 GMT." <20050222161520.GA22555@mail.shareable.org>
X-Organization: Hewlett-Packard Labs, Large Scale Systems group
Date: Tue, 22 Feb 2005 10:38:04 -0800
X-Mts: smtp
X-Spam-Score: 0 ()
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-Mailman-Approved-At: Tue, 22 Feb 2005 10:41:19 -0800
Cc: WebDAV <w3c-dist-auth@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: [Ietf-caldav] Re: draft-reschke-http-addmember-00
X-BeenThere: ietf-caldav@osafoundation.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:ietf-caldav@osafoundation.org>
List-Help: <mailto:ietf-caldav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Feb 2005 18:38:09 -0000

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