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

Justin Chapweske <justin@chapweske.com> Tue, 22 February 2005 21:00 UTC

X-Envelope-From: justin@chapweske.com
X-Envelope-To: <ietf-caldav@osafoundation.org>
Received: from sm1255.hostcentric.net (endo.onionnetworks.com [216.65.116.22]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1ML08aa018918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-caldav@osafoundation.org>; Tue, 22 Feb 2005 13:00:08 -0800
Received: (qmail 31166 invoked by uid 107); 22 Feb 2005 20:57:46 -0000
Received: from c-66-41-30-194.mn.client2.attbi.com (HELO ?192.168.0.5?) (justin@onionnetworks.com@66.41.30.194) by endo.onionnetworks.com with RC4-MD5 encrypted SMTP; 22 Feb 2005 20:57:46 -0000
Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00
From: Justin Chapweske <justin@chapweske.com>
To: Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <421B5F72.6070806@gmx.de>
References: <20050221213247.GB8870@mail.shareable.org> <OF37A764C1.8369E90C-ON85256FAF.007C29A8-87256FB0.0018408A@us.ibm.com> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de>
Content-Type: text/plain
Date: Tue, 22 Feb 2005 14:56:47 -0600
Message-Id: <1109105807.10284.229.camel@bog>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.3 (2.0.3-0.mozer.1)
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.05 () FORGED_RCVD_HELO
X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1
X-Mailman-Approved-At: Fri, 25 Feb 2005 09:10:57 -0800
Cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, HTTP Working Group <ietf-http-wg@w3.org>, Jamie Lokier <jamie@shareable.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 21:00:08 -0000

> > A CalDAV or Atom client accesses a resource that it is told to access.
> > 
> > In all cases, the client is told to try certain methods on certain
> > URLs, by the user (or other agent).
> > 
> > If the user asks a client to try WebDAV methods on a resource that
> > they don't know it's safe to try WebDAV methods on, then they can
> > cause all sorts of havoc.
> 
> If that causes havoc, that's because the server is broken (be it 
> misconfigured or just buggy).

Amen.  Allowing poor implementations to dictate the evolution of HTTP
can only lead to further inconsistencies and ambiguities which lead to
more bugs and security holes.

I'm still rather grumpy about how many dozens of hours my developers
wasted getting iTunes to work through our proxy due to the liberties
that Icecast has taken with HTTP.  I was appalled when I learned they
return "ICY 200 OK" for a valid HTTP request.

I think the PATCH proposal is good as it fills in a huge hole, but I am
much less excited about ADDMEMBER because now we have a whole new verb
that we have to understand the security ramifications and caching
semantics for.

-- 
Justin Chapweske <justin@chapweske.com>