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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 17 Feb 2005 21:07:15 +0100
Message-ID: <4214F973.9060404@gmx.de>
To: Scott Lawrence <scott@skrb.org>
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>

Scott Lawrence wrote:
> 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.

In which case I couldn't use the content-type of my actual request body 
for the Content-Type request header, right?

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

I am one of these WebDAV implementors, thanks. I haven't had any issues 
with issues for a long time.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 17 February 2005 20:35:47 GMT

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