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

Jamie Lokier <jamie@shareable.org> Tue, 22 February 2005 20:38 UTC

X-Envelope-From: jamie@shareable.org
X-Envelope-To: <ietf-caldav@osafoundation.org>
Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1MKcfaa011733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-caldav@osafoundation.org>; Tue, 22 Feb 2005 12:38:44 -0800
Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1MKcd81026770; Tue, 22 Feb 2005 20:38:39 GMT
Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1MKcdcT026767; Tue, 22 Feb 2005 20:38:39 GMT
Date: Tue, 22 Feb 2005 20:38:39 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Julian Reschke <julian.reschke@gmx.de>
Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00
Message-ID: <20050222203839.GE22555@mail.shareable.org>
References: <20050221213247.GB8870@mail.shareable.org> <OF37A764C1.8369E90C-ON85256FAF.007C29A8-87256FB0.0018408A@us.ibm.com> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <421B5F72.6070806@gmx.de>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0 ()
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, HTTP Working Group <ietf-http-wg@w3.org>, WebDAV <w3c-dist-auth@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
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 20:38:48 -0000

Julian Reschke wrote:
> >For example, a WebDAV client accesses a resource because the user
> >tells the client to.  The user is allowing the client to assume that
> >WebDAV methods are ok to try on the resource.
> 
> You're making assumptions about the knowledge a user has that IMHO are 
> simply questionable. For instance, a user my use IE to follow a 
> hyperlink to an Office document, and Office will (under some 
> circumstances) LOCK the document, and later PUT and UNLOCK it. At least 
> 95% of the users will not be aware of what was going on technically.

It's not assumption about the user's knowledge.  It's an unavoidable
assumption the client must make, that it's invoked on an appropriate
kind of resource.

If a user does that, and the document came from a CGI script of the
low quality I've seen, there's a good chance the LOCK and PUT
operations will invoke unwanted side effects - or just overwrite the
script.

Of course if it's a better written web component then it won't have
those problems.  And something that generates and returns Office files
probably is better written in that respect.

> >There is simply no way for the client to "discover" whether a given
> >URL supports the behaviour it's been asked to do, without causing
> >potential harmful side effects.
> 
> Jamie, lots of clients are doing this today. I'm not aware of any 
> "havoc" causing this.

How often do you look at Joe Random form results and then select "edit
this page"?  If you do that with random forms from the web, I think
you'll be surprised at how many don't respond sensibly to OPTIONS,
LOCK and PUT.

The slackness doesn't cause problems because people don't do that.
(And in the cases where they do, because it's appropriate for a resource,
that resource implements a sensible response).

Similarly, how often do you expect CalDAV clients to be pointed at
non-CalDAV URLs?

If it's done, the behaviour of the server is unpredictable.  ADDMEMBER
doesn't fix that.

(Although it would shift the likelihood towards a simple failure
rather than an unwanted side effect.  Is it worth creating a new
method just to change the likelihood of a behaviour when a CalDAV
client is pointed at the wrong URL?)

-- Jamie