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

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

From: Scott Lawrence <scott@skrb.org>
Date: Thu, 17 Feb 2005 15:00:49 -0500
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Cyrus Daboo <daboo@isamet.com>, Jamie Lokier <jamie@shareable.org>, Mark Baker <distobj@acm.org>, "Roy T. Fielding" <fielding@gbiv.com>, WebDAV <w3c-dist-auth@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
Message-Id: <1108670449.11773.33.camel@sukothai.pingtel.com>

On Thu, 2005-02-17 at 19:39 +0100, Julian Reschke wrote:
> Scott Lawrence wrote:
> > That statement misses the point - it may be true that it's difficult to
> > express the access control based just on the method, but that doesn't
> > mean that it's difficult to implement appropriate access control in
> > either the client or the server.  The method alone does not specify the
> > operation - indeed, in the case of POST the full specification of the
> > operation is deliberately expanded to include the body mime type and the
> > body content.
> > 
> > I don't think you've shown how what you're trying to do is any different
> > from what POST has always done.
> 
> It's a aubset with well-defined semantics. I consider this a feature.

But you could just as easily and precisely define those semantics by
using POST and defining the mime type and operations it supports.

You won't get caught be firewalls and proxy servers that think they know
better about what methods are legitimate (which you most assuredly will
if you create a new method - ask the WebDav implementors), and you won't
have changed the semantics of the method at all.
Received on Thursday, 17 February 2005 20:00:53 GMT

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