X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1SKv0aZ028951 for ; Mon, 28 Feb 2005 12:57:01 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Feb 2005 14:58:12 -0600 Message-ID: <422385AF.4000001@progbits.com> Date: Mon, 28 Feb 2005 14:57:19 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] Owner of caldav.org?? References: <3a1b1679f706c6685b0ab009dcefdbee@osafoundation.org> In-Reply-To: <3a1b1679f706c6685b0ab009dcefdbee@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2005 20:58:12.0984 (UTC) FILETIME=[376B2F80:01C51DD8] X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 20:57:03 -0000 ns1@thejkgroup.com Looks like the registrar though. They may be able to help a little more. Looking at the page it appears that you are the owner... ;-) Lisa Dusseault wrote: > Does anybody know who the owner of caldav.org is? That domain has > currently got a frame showing the CalDAV resources page I put up a few > weeks ago (http://ietf.webdav.org/caldav) but we don't know how long > that will last or whether to count on it. > > thx, > Lisa > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1SKXMaa024519 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 28 Feb 2005 12:33:28 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <3a1b1679f706c6685b0ab009dcefdbee@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: CalDAV DevList From: Lisa Dusseault Date: Mon, 28 Feb 2005 12:33:16 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Owner of caldav.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 20:33:29 -0000 Does anybody know who the owner of caldav.org is? That domain has currently got a frame showing the CalDAV resources page I put up a few weeks ago (http://ietf.webdav.org/caldav) but we don't know how long that will last or whether to count on it. thx, Lisa X-Envelope-From: distobj@acm.org X-Envelope-To: Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1P5ZgaZ002756 for ; Thu, 24 Feb 2005 21:35:42 -0800 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D4Y85-0004GV-00; Fri, 25 Feb 2005 00:35:09 -0500 Date: Fri, 25 Feb 2005 00:35:09 -0500 From: Mark Baker To: HTTP Working Group , CalDAV DevList , WebDAV WG Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050225053508.GA16308@markbaker.ca> References: <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> <20050223042608.GF4504@markbaker.ca> <9ee689aeebb609c273b25296ff535c51@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ee689aeebb609c273b25296ff535c51@gbiv.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2005 05:35:43 -0000 On Wed, Feb 23, 2005 at 12:24:07AM -0800, Roy T. Fielding wrote: > On Feb 22, 2005, at 8:26 PM, Mark Baker wrote: > >I still don't see how POST vs. ADDMEMBER is any different than POST > >vs. PUT. You previously said that PUT has "set the state of this > >resource" semantics which is clearly different than POST. IMO, > >ADDMEMBER's semantics are very similar to PUT. What (constraint?) am > >I missing that suggests PUT is fine while ADDMEMBER isn't? > > You are missing that the target of PUT is the new resource, > whereas the target of POST and ADDMEMBER are both the collection > resource. As such, ADDMEMBER's semantics has very little in > common with PUT (almost nothing, in fact, since any unsafe > extension method can return 201 and communicate just as much, > whereas PUT is unique in what it communicates by the 200/201). In case anybody's still following this thread 8-) ... I now find myself in agreement with Roy, that POST is appropriate and that ADDMEMBER == POST. I was looking at the interaction from the POV of a tweak on PUT semantics, rather than as the submission of a document to a state-preserving container (which I should have recognized it as immediately, given my previous attempts at describing such a model[1]). I'm still not convinced that a POST extension (which declared the expected type of the target resource) wouldn't improve the self-descriptiveness of the message, but practically, that's pretty much irrelevant for the purposes of this discussion. [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from fed1rmmtao03.cox.net (fed1rmmtao03.cox.net [68.230.241.36]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1N8URaZ006354 for ; Wed, 23 Feb 2005 00:30:27 -0800 Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050223083022.GFSW1282.fed1rmmtao03.cox.net@[192.168.0.100]>; Wed, 23 Feb 2005 03:30:22 -0500 In-Reply-To: <20050223042608.GF4504@markbaker.ca> References: <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> <20050223042608.GF4504@markbaker.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9ee689aeebb609c273b25296ff535c51@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Wed, 23 Feb 2005 00:24:07 -0800 To: Mark Baker X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 08:30:28 -0000 On Feb 22, 2005, at 8:26 PM, Mark Baker wrote: > I still don't see how POST vs. ADDMEMBER is any different than POST > vs. PUT. You previously said that PUT has "set the state of this > resource" semantics which is clearly different than POST. IMO, > ADDMEMBER's semantics are very similar to PUT. What (constraint?) am > I missing that suggests PUT is fine while ADDMEMBER isn't? You are missing that the target of PUT is the new resource, whereas the target of POST and ADDMEMBER are both the collection resource. As such, ADDMEMBER's semantics has very little in common with PUT (almost nothing, in fact, since any unsafe extension method can return 201 and communicate just as much, whereas PUT is unique in what it communicates by the 200/201). ....Roy X-Envelope-From: distobj@acm.org X-Envelope-To: Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1N4QkaZ031597 for ; Tue, 22 Feb 2005 20:26:46 -0800 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D3o6C-0004B2-00; Tue, 22 Feb 2005 23:26:08 -0500 Date: Tue, 22 Feb 2005 23:26:08 -0500 From: Mark Baker To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050223042608.GF4504@markbaker.ca> References: <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 04:26:49 -0000 On Tue, Feb 22, 2005 at 11:52:55AM -0800, Roy T. Fielding wrote: > On Feb 22, 2005, at 5:37 AM, Mark Baker wrote: > >Ah, so you're saying that ADDMEMBER isn't uniform? > > Actually, no, I was saying that ADDMEMBER as currently defined > is identical to POST. Julian said that it wasn't identical because > his client would be able to expect one semantic, namely that a > 201 result would cause the webdav collection to contain a new > member with the given media type. That implies an additional > requirement that the target be a webdav collection, which isn't > uniform at all. I get the DAV-collection-implies-non-uniform thing, and would be against a revision which attributed that meaning to a 201 response. But I'm just not seeing how ADDMEMBER==POST, sorry. I still don't see how POST vs. ADDMEMBER is any different than POST vs. PUT. You previously said that PUT has "set the state of this resource" semantics which is clearly different than POST. IMO, ADDMEMBER's semantics are very similar to PUT. What (constraint?) am I missing that suggests PUT is fine while ADDMEMBER isn't? Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from sccrmhc11.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1N2pxaZ024904 for ; Tue, 22 Feb 2005 18:52:00 -0800 Received: from computer.comcast.net (pcp02547528pcs.micske01.fl.comcast.net[68.84.21.89]) by comcast.net (sccrmhc14) with SMTP id <2005022302515201400sdou5e>; Wed, 23 Feb 2005 02:51:52 +0000 Message-Id: <6.2.1.2.0.20050222214232.02d17480@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 22 Feb 2005 21:50:14 -0500 To: "ietf-caldav@osafoundation.org" From: Tim Hare Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.22 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, TO_ADDRESS_EQ_REAL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Time for a little clarification for the non -gurus? X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 02:52:00 -0000 I'm not an HTTP guru, so I am asking for clarification. It sound to me like we are discussing the difference between: A: Many different methods (ADDMEMBER, MKCOL, etc.) applied to one URL - i.e. the URL is the identification of the "object" which implements those methods. I.e. We do MKCOL and ADDMEMBER both to my.implementation.of.this.com, and the method determines what is done. VS. B: A simple set of methods, the original HTTP 1.1 methods (or maybe just POST?) applied to many different URLs, with the URL representing a resource that knows what to do when it receives that. A POST to makecollection.my.implementation.of.this.com/collection_name does one thing, a POST to addmember.my.implementation.of.this.com/collection_name/member_name does another. As I said I'm asking for clarification. I could be totally wrong about both A and B - but I would like to know, in simpler terms, the two sides of this discussion (there may in fact be three or nine, because I've gotten lost) Thanks Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: scott@skrb.org X-Envelope-To: Received: from mail.pingtel.com (user3.pingtel.com [65.220.123.3] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1MMFwaZ030705 for ; Tue, 22 Feb 2005 14:15:58 -0800 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 71EDE6C021; Tue, 22 Feb 2005 17:15:57 -0500 (EST) Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 From: Scott Lawrence To: Julian Reschke In-Reply-To: <421B7F59.5080702@gmx.de> References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <1109097394.6051.1.camel@sukothai.pingtel.com> <421B7F59.5080702@gmx.de> Content-Type: text/plain Organization: http://skrb.org/scott/ Date: Tue, 22 Feb 2005 17:15:57 -0500 Message-Id: <1109110557.6051.49.camel@sukothai.pingtel.com> 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 Cc: Geoffrey M Clemm , HTTP Working Group , Jamie Lokier , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 22:16:00 -0000 On Tue, 2005-02-22 at 19:52 +0100, Julian Reschke wrote: > Scott Lawrence wrote: > > On Tue, 2005-02-22 at 17:36 +0100, Julian Reschke wrote: > > > >>So what do I do if a have a resource that accepts HTML form posts, > >>SOAP > >>requests and ADDMEMBER-like semantics on the same URL? > > > > > > Either: > > > > - Implement it very very carefully. > > Hm. What exactly does that mean? It means that that resource should have a well defined way of determining what it is being asked to do for any given request. Personally, I would choose the second alternative - use different URLs for those different purposes, but... > When POST is applied to that resource with a content type of > "application/soap+xml", is it supposed to store the attached entity as a > new resource (with content type "application/soap+xml", returning a > Location response header with the URL of the new resource), or should it > process it according to > ? That W3C spec does not mandate that anything in particular be done with a request body with that mime type. It in no way requires that a request body with that mime type invoke a SOAP operation or prevents a given URL from treating that body as an object to be stored. X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MMB0aZ030120 for ; Tue, 22 Feb 2005 14:11:01 -0800 Received: (qmail invoked by alias); 22 Feb 2005 22:10:53 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp009) with SMTP; 22 Feb 2005 23:10:53 +0100 X-Authenticated: #1915285 Message-ID: <421BADE0.6060105@gmx.de> Date: Tue, 22 Feb 2005 23:10:40 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <421B8CDE.6000201@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 22:11:05 -0000 Roy T. Fielding wrote: > ... >> By defining a way to discover WebDAV collections >> (DAV:resourcetype/DAV:collection in PROPFIND response), a client can >> find out whether a resource is a WebDAV collection or isn't. Also, >> WebDAV defines COPY and MOVE as namespace operations that take >> containment into account. > > > Completely irrelevant -- COPY and MOVE are HTTP operations on any > collection, not just webdav collections, and will succeed or fail > regardless of whether the client previously checked its pacifier. Yes, but that doesn't mean it's irrelevant whether a resource is a collection or not. It just means that you don't *have* to check before you apply namespace operations. >> I'm not sure why this is a problem; and in particular I'd like to know >> what a better solution would have been. > > > There was no problem -- it was a solution to someone's angst. So how *should* a WebDAV collection have been defined? >>> absolutely moronic implementations that have to test each resource >>> for the set of methods it implements before performing a set of >>> actions that would have the same result as a generic POST. >> >> >> Right, those are moronic implementations (because in general, a client >> can safely try the method and then handle HTTP's "method not allowed" >> status code gracefully). >> >> On the other hand, using distinct methods allows to use a >> discovery/failure signalling approach that uses plain HTTP (OPTIONS >> method, "Allow" response header, 405 status). > > > Which is completely unnecessary in HTTP. The 405 status and the Allow response header are unnecessary? >>> [Which is to say that it will suck every bit as much as the other >>> methods introduced by webdav and its prodigy that created arbitrary >>> resource types for collections, versions, and now calendars.] >> >> >> Nit: Versions aren't special resource types. > > > Sorry, I meant MKWORKSPACE. The alternative would have been just to use standard resources, but in that case RFC3253 would have had to define some new way to indicate that something indeed is a workspace. >>> POST, in contrast, is a generic semantic that allows the resource >>> to determine its implementation-specific effects. POST to a >>> collection means add a member. POST to a PUT-able resource means >>> an atomic append. POST to a messaging gateway means "post this". >> >> >> Why can't a collection be PUT-able? > > > It could have been, but MKCOL was defined instead (over my objection). There is nothing in RFC2518 that prevents collections from being PUT-able (however the rational for not defining PUT on collections is a bit weird, see ). >> OK, so that sounds to me like resources should fall into distinct >> categories: >> >> (A1) Collections vs (A2) Non-Collections >> (B1) Put-able vs (B2) Non-Put-able >> >> - resources of type A1 would understand POST request as having >> "ADDMEMBER" semantics >> >> - resources of type A2 can (within reason) do anything they like with >> POST (as long as compliant to RFC2616) >> >> - resources of type B1 will allow PUT (as defined by RFC2616) and >> understand POST as "append" operation >> >> Let's consider a simple WebDAV server that supports only resources of >> types A1 and B1. What's the recommendation to do authoring operations >> beyond PUT on these resources? Define new methods (such as >> VERSION-CONTROL) or mint new related URLs to which existing methods >> can be applied? > > > Different URLs (see, for example, how the configurable name "index" > is a member of a collection and also the default response to GET > on that collection). How a PUT or POST or any other method applied > to the collection is handled is just as configurable and may depend > on other aspects of the request (like content-type, authentication, > and more). PUT is usually redirected to the index URL because > namespace operations are typically done one name at a time rather ...when you say "typically", what implementation are you referring to? Is this implemented in Apache/mod_dav? > than entire collections at a time, however that is dependent on the > implementation: when a client does a PUT of an XML document to a > JCR-backed implementation, it will create a collection (a document > is just one view of the collection). > > Each resource has an implementation and that implementation defines > how the method impacts its state aside from what is already defined > by virtue of HTTP's method semantics. The reason we don't need > ADDMEMBER is because POST already exists, a server must inspect > the media type already, and none of the overlapping uses of POST > are valid new members to add to a collection (soap envelopes or > www/x-form-urlencoded). It is therefore possible to say that POST Interesting. Why wouldn't a SOAP envelope be a valid new collection member? And what about other potential content types resources could already implement for POST (that just happen to be proprietary)? > has the add member effect on a webdav collection and be done. > > ....Roy Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MLflaZ023653 for ; Tue, 22 Feb 2005 13:41:47 -0800 Received: (qmail invoked by alias); 22 Feb 2005 21:41:16 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp024) with SMTP; 22 Feb 2005 22:41:16 +0100 X-Authenticated: #1915285 Message-ID: <421BA6F6.2000804@gmx.de> Date: Tue, 22 Feb 2005 22:41:10 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <20050222203839.GE22555@mail.shareable.org> <421B9A6F.7050206@gmx.de> <20050222211908.GH22555@mail.shareable.org> In-Reply-To: <20050222211908.GH22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Geoffrey M Clemm , HTTP Working Group , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 21:41:50 -0000 Jamie Lokier wrote: >>You keep saying that :-) So are you saying that defining new methods >>never ever is the right approach, because there are broken servers out >>there? > > > No I'm not saying that. > > One of the rationales given in this thread for ADDMEMBER is that the > tighter semantics mean that clients can depend on it literally adding > a new resource which is GETable, or failing with Method Not Supported. > > I'm saying that particular rationale isn't logically sound. ADDMEMBER is defined to do just that. If it would be accepted and become a standards-track RFC, yes, clients could rely on it just like they can rely on other HTTP methods today. > It doesn't negate any other rationales you may have up your sleeve :) > > >>ADDMEMBER is a generic method. It doesn't have anything specific to do >>with CalDAV except that it *could* be used with CalDAV. > > > Indeed, but are there realistic applications in mind that would use > ADDMEMBER without caring what kind of container resource it is, but do > care that it is a container and not a form processor? Yes. For instance it could be used for Atom-Pub, and another use case was just suggested a few days ago internally at SAP (where a specific backend system has a concept of containment, but doesn't allow user-selected URIs). > If there are it makes more sense. If there aren't, it's unneeded. > > I think your exploration of the WebDAV text concerning why POST isn't > used on containers is a good one, btw. I appreciate all the feedback I'm getting, and I'm very interested in ways that would avoid adding a new method while keeping the intended benefits. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1MLJOaa021509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 13:19:26 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1MLJ881027280; Tue, 22 Feb 2005 21:19:08 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1MLJ8Qj027278; Tue, 22 Feb 2005 21:19:08 GMT Date: Tue, 22 Feb 2005 21:19:08 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 Message-ID: <20050222211908.GH22555@mail.shareable.org> References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <20050222203839.GE22555@mail.shareable.org> <421B9A6F.7050206@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421B9A6F.7050206@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 , HTTP Working Group , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 21:19:27 -0000 Julian Reschke wrote: > Jamie Lokier wrote: > >... > >If it's done, the behaviour of the server is unpredictable. ADDMEMBER > >doesn't fix that. > >... > > You keep saying that :-) So are you saying that defining new methods > never ever is the right approach, because there are broken servers out > there? No I'm not saying that. One of the rationales given in this thread for ADDMEMBER is that the tighter semantics mean that clients can depend on it literally adding a new resource which is GETable, or failing with Method Not Supported. I'm saying that particular rationale isn't logically sound. It doesn't negate any other rationales you may have up your sleeve :) > ADDMEMBER is a generic method. It doesn't have anything specific to do > with CalDAV except that it *could* be used with CalDAV. Indeed, but are there realistic applications in mind that would use ADDMEMBER without caring what kind of container resource it is, but do care that it is a container and not a form processor? If there are it makes more sense. If there aren't, it's unneeded. I think your exploration of the WebDAV text concerning why POST isn't used on containers is a good one, btw. -- Jamie X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1ML29aa019186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 13:02:09 -0800 Received: from ip68-4-71-218.oc.oc.cox.net ([68.4.71.218] helo=[192.168.0.100]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3hAS-0008GN-SB; Tue, 22 Feb 2005 13:02:04 -0800 In-Reply-To: <421B8CDE.6000201@gmx.de> References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <421B8CDE.6000201@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Tue, 22 Feb 2005 13:01:57 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 21:02:26 -0000 On Feb 22, 2005, at 11:49 AM, Julian Reschke wrote: > Roy T. Fielding wrote: >> On Feb 21, 2005, at 7:46 PM, Mark Baker wrote: >>> Let me ask this; why do we have PUT when a valid effect of a POST >>> could also be to set the state of a resource? >> Because PUT means set the state of this resource, whereas POST >> does not. >>> IMO, it's because there are advantages to having messages which >>> reflect >>> the expectations of their sender. >> Umm, think about that sentence and you will find it has no content. >> Messages reflect the instruction of the sender. POST does that. > > Agreed. But for POST, this only seems to work where there is a tight > coupling between client and server; otherwise the client will have no > clue about the server will indeed do with the request. The client doesn't need to know. An HTTP client does not know the reason why a request is being made, just as it does not know the text inside the anchor of a hypertext link that was clicked on to generate a GET request. The user (agent) builds up state based on a huge number of factors, including what is said in all past representations received, degrees of trust, instructions that may have been received via some other channel, configuration, etc. That is what tells the user what to expect. HTTP doesn't care. What HTTP cares about is that the method is unsafe, the response is not (by default) cacheable, a new resource has been created (201), and it can be found at a given Location. > By defining a way to discover WebDAV collections > (DAV:resourcetype/DAV:collection in PROPFIND response), a client can > find out whether a resource is a WebDAV collection or isn't. Also, > WebDAV defines COPY and MOVE as namespace operations that take > containment into account. Completely irrelevant -- COPY and MOVE are HTTP operations on any collection, not just webdav collections, and will succeed or fail regardless of whether the client previously checked its pacifier. > I'm not sure why this is a problem; and in particular I'd like to know > what a better solution would have been. There was no problem -- it was a solution to someone's angst. >> absolutely moronic implementations that have to test each resource >> for the set of methods it implements before performing a set of >> actions that would have the same result as a generic POST. > > Right, those are moronic implementations (because in general, a client > can safely try the method and then handle HTTP's "method not allowed" > status code gracefully). > > On the other hand, using distinct methods allows to use a > discovery/failure signalling approach that uses plain HTTP (OPTIONS > method, "Allow" response header, 405 status). Which is completely unnecessary in HTTP. >> [Which is to say that it will suck every bit as much as the other >> methods introduced by webdav and its prodigy that created arbitrary >> resource types for collections, versions, and now calendars.] > > Nit: Versions aren't special resource types. Sorry, I meant MKWORKSPACE. >> POST, in contrast, is a generic semantic that allows the resource >> to determine its implementation-specific effects. POST to a >> collection means add a member. POST to a PUT-able resource means >> an atomic append. POST to a messaging gateway means "post this". > > Why can't a collection be PUT-able? It could have been, but MKCOL was defined instead (over my objection). > OK, so that sounds to me like resources should fall into distinct > categories: > > (A1) Collections vs (A2) Non-Collections > (B1) Put-able vs (B2) Non-Put-able > > - resources of type A1 would understand POST request as having > "ADDMEMBER" semantics > > - resources of type A2 can (within reason) do anything they like with > POST (as long as compliant to RFC2616) > > - resources of type B1 will allow PUT (as defined by RFC2616) and > understand POST as "append" operation > > Let's consider a simple WebDAV server that supports only resources of > types A1 and B1. What's the recommendation to do authoring operations > beyond PUT on these resources? Define new methods (such as > VERSION-CONTROL) or mint new related URLs to which existing methods > can be applied? Different URLs (see, for example, how the configurable name "index" is a member of a collection and also the default response to GET on that collection). How a PUT or POST or any other method applied to the collection is handled is just as configurable and may depend on other aspects of the request (like content-type, authentication, and more). PUT is usually redirected to the index URL because namespace operations are typically done one name at a time rather than entire collections at a time, however that is dependent on the implementation: when a client does a PUT of an XML document to a JCR-backed implementation, it will create a collection (a document is just one view of the collection). Each resource has an implementation and that implementation defines how the method impacts its state aside from what is already defined by virtue of HTTP's method semantics. The reason we don't need ADDMEMBER is because POST already exists, a server must inspect the media type already, and none of the overlapping uses of POST are valid new members to add to a collection (soap envelopes or www/x-form-urlencoded). It is therefore possible to say that POST has the add member effect on a webdav collection and be done. ....Roy X-Envelope-From: justin@chapweske.com X-Envelope-To: 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 ; 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 To: Julian Reschke In-Reply-To: <421B5F72.6070806@gmx.de> References: <20050221213247.GB8870@mail.shareable.org> <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 , HTTP Working Group , Jamie Lokier , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MKnUaZ014131 for ; Tue, 22 Feb 2005 12:49:31 -0800 Received: (qmail invoked by alias); 22 Feb 2005 20:49:25 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp002) with SMTP; 22 Feb 2005 21:49:25 +0100 X-Authenticated: #1915285 Message-ID: <421B9ACF.8040807@gmx.de> Date: Tue, 22 Feb 2005 21:49:19 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier References: <20050221213247.GB8870@mail.shareable.org> <421B6778.1080804@gmx.de> <20050222190228.GD22555@mail.shareable.org> <421B86CC.7020402@gmx.de> <20050222204226.GF22555@mail.shareable.org> In-Reply-To: <20050222204226.GF22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Geoffrey M Clemm , HTTP Working Group , WebDAV , CalDAV DevList 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:49:32 -0000 Jamie Lokier wrote: > Julian Reschke wrote: > >>>You're missing that when you are doing CalDAV* requests, you _know_ the >>>URL you are accessing is CalDAV compliant already. (* - example). >> >>How does a client do *any* kind of server feature discovery if *any* >>method (including things like OPTIONS) may cause harm because of broken >>server implementations? > > > Even when you can trust OPTIONS, that's not going to tell you if it's > a CalDAV resource - only what methods are accepted. I'm not interested whether it's a CalDAV resource. I'm interested in whether it supports ADDMEMBER. > You do feature discovery - in other words, which URL points to a > calendar - in other ways. > > >>>If you don't know that you have big problems. >> >>Such as? > > > Such as trying to treat a non-calendar resource as a calender! :) And the problem resulting from that would be what exactly? A CalDAV calendar (as currently proposed) is just a WebDAV collection with some specific features. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MKm0aZ013271 for ; Tue, 22 Feb 2005 12:48:01 -0800 Received: (qmail invoked by alias); 22 Feb 2005 20:47:54 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp020) with SMTP; 22 Feb 2005 21:47:54 +0100 X-Authenticated: #1915285 Message-ID: <421B9A6F.7050206@gmx.de> Date: Tue, 22 Feb 2005 21:47:43 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <20050222203839.GE22555@mail.shareable.org> In-Reply-To: <20050222203839.GE22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Geoffrey M Clemm , HTTP Working Group , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:48:04 -0000 Jamie Lokier wrote: > ... > If it's done, the behaviour of the server is unpredictable. ADDMEMBER > doesn't fix that. > ... You keep saying that :-) So are you saying that defining new methods never ever is the right approach, because there are broken servers out there? If that's the case, let's just agree that we disagree. > (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?) ADDMEMBER is a generic method. It doesn't have anything specific to do with CalDAV except that it *could* be used with CalDAV. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1MKgWaa011919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 12:42:33 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1MKgQ81026817; Tue, 22 Feb 2005 20:42:26 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1MKgQ69026815; Tue, 22 Feb 2005 20:42:26 GMT Date: Tue, 22 Feb 2005 20:42:26 +0000 From: Jamie Lokier To: Julian Reschke Message-ID: <20050222204226.GF22555@mail.shareable.org> References: <20050221213247.GB8870@mail.shareable.org> <421B6778.1080804@gmx.de> <20050222190228.GD22555@mail.shareable.org> <421B86CC.7020402@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421B86CC.7020402@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 , HTTP Working Group , WebDAV , CalDAV DevList 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:42:34 -0000 Julian Reschke wrote: > >You're missing that when you are doing CalDAV* requests, you _know_ the > >URL you are accessing is CalDAV compliant already. (* - example). > > How does a client do *any* kind of server feature discovery if *any* > method (including things like OPTIONS) may cause harm because of broken > server implementations? Even when you can trust OPTIONS, that's not going to tell you if it's a CalDAV resource - only what methods are accepted. You do feature discovery - in other words, which URL points to a calendar - in other ways. > >If you don't know that you have big problems. > > Such as? Such as trying to treat a non-calendar resource as a calender! :) -- Jamie X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 ; 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 To: Julian Reschke Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 Message-ID: <20050222203839.GE22555@mail.shareable.org> References: <20050221213247.GB8870@mail.shareable.org> <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 , HTTP Working Group , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MK29aZ009130 for ; Tue, 22 Feb 2005 12:02:09 -0800 Received: (qmail invoked by alias); 22 Feb 2005 20:02:03 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp018) with SMTP; 22 Feb 2005 21:02:03 +0100 X-Authenticated: #1915285 Message-ID: <421B8FB3.6050102@gmx.de> Date: Tue, 22 Feb 2005 21:01:55 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 20:02:10 -0000 Roy T. Fielding wrote: > > On Feb 22, 2005, at 5:37 AM, Mark Baker wrote: > >> Ah, so you're saying that ADDMEMBER isn't uniform? > > > Actually, no, I was saying that ADDMEMBER as currently defined > is identical to POST. Julian said that it wasn't identical because > his client would be able to expect one semantic, namely that a > 201 result would cause the webdav collection to contain a new > member with the given media type. That implies an additional > requirement that the target be a webdav collection, which isn't > uniform at all. I'm not sure how you get to that conclusion. ADDMEMBER (as proposed) doesn't require the target resouce to be a WebDAV collection. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1MJqxaa008231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 11:52:59 -0800 Received: from ip68-4-71-218.oc.oc.cox.net ([68.4.71.218] helo=[192.168.0.100]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3g5a-0008KE-9P; Tue, 22 Feb 2005 11:52:58 -0800 In-Reply-To: <20050222133758.GD4504@markbaker.ca> References: <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> <20050222133758.GD4504@markbaker.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Tue, 22 Feb 2005 11:52:55 -0800 To: Mark Baker X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:53:00 -0000 On Feb 22, 2005, at 5:37 AM, Mark Baker wrote: > Ah, so you're saying that ADDMEMBER isn't uniform? Actually, no, I was saying that ADDMEMBER as currently defined is identical to POST. Julian said that it wasn't identical because his client would be able to expect one semantic, namely that a 201 result would cause the webdav collection to contain a new member with the given media type. That implies an additional requirement that the target be a webdav collection, which isn't uniform at all. > Can you give an example of a resource > for which ADDMEMBER wouldn't make sense? No, which is why it is POST by any other name. ....Roy X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MJo1aZ007893 for ; Tue, 22 Feb 2005 11:50:02 -0800 Received: (qmail invoked by alias); 22 Feb 2005 19:49:55 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp006) with SMTP; 22 Feb 2005 20:49:55 +0100 X-Authenticated: #1915285 Message-ID: <421B8CDE.6000201@gmx.de> Date: Tue, 22 Feb 2005 20:49:50 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> In-Reply-To: <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:50:04 -0000 Roy T. Fielding wrote: > > On Feb 21, 2005, at 7:46 PM, Mark Baker wrote: > >> Let me ask this; why do we have PUT when a valid effect of a POST >> could also be to set the state of a resource? > > > Because PUT means set the state of this resource, whereas POST > does not. > >> IMO, it's because there are advantages to having messages which reflect >> the expectations of their sender. > > > Umm, think about that sentence and you will find it has no content. > Messages reflect the instruction of the sender. POST does that. Agreed. But for POST, this only seems to work where there is a tight coupling between client and server; otherwise the client will have no clue about the server will indeed do with the request. > What you are really saying is that there are advantages to the > client knowing the nature of a resource, encoding that nature > into the set of methods used, and thus forcing how its state > will be impacted by each messaged action. That is what Julian > wants in an ADDMEMBER method. You, of all people, should > be the first to recognize that slippery slope. > > Yes, it has advantages, but it also has far-reaching disadvantages > that HTTP was designed to prevent. It causes clients to become > coupled to particular "types" of resources on the server, which > is just another from of implementation-dependency. It leads to Well yes; let's take a look at WebDAV collections, part of the WebDAV requirements written down in RFC2291 (). By defining a way to discover WebDAV collections (DAV:resourcetype/DAV:collection in PROPFIND response), a client can find out whether a resource is a WebDAV collection or isn't. Also, WebDAV defines COPY and MOVE as namespace operations that take containment into account. I'm not sure why this is a problem; and in particular I'd like to know what a better solution would have been. > absolutely moronic implementations that have to test each resource > for the set of methods it implements before performing a set of > actions that would have the same result as a generic POST. Right, those are moronic implementations (because in general, a client can safely try the method and then handle HTTP's "method not allowed" status code gracefully). On the other hand, using distinct methods allows to use a discovery/failure signalling approach that uses plain HTTP (OPTIONS method, "Allow" response header, 405 status). > [Which is to say that it will suck every bit as much as the other > methods introduced by webdav and its prodigy that created arbitrary > resource types for collections, versions, and now calendars.] Nit: Versions aren't special resource types. > POST, in contrast, is a generic semantic that allows the resource > to determine its implementation-specific effects. POST to a > collection means add a member. POST to a PUT-able resource means > an atomic append. POST to a messaging gateway means "post this". Why can't a collection be PUT-able? > POST to any other resource means "process this". Note, however, > that to a client they all mean the same thing: take this data > and apply it in accordance with your nature. The client does > not need to know anything more because the client already knows > what it wants to do (and knowing more cannot help it, since > only the server is allowed to know the implementation). > > PUT versus PATCH might lead you to an interesting comparison, > at least in terms of seeing when two methods do have different > semantics. A better example is POST versus PATCH, given that > PATCHing a collection could be defined as a set of add/remove > operations on the collection state. One could easily define a > patch media type for that, but there are also good reasons not to. > > POST versus ADDMEMBER, however, does not compare at all because > POST is already defined to be "add a member." POST only seems to > have multiple definitions because the other definitions are > examples of various forms of partial state change within a > resource that may consist of identifiable subcomponents. It is > really just one semantic definition that manifests in different > ways based upon how the implementer views the resource to which > the POST is applied. A file is just an ordered collection of bytes. > A collection is just a file with a compound media type. A gateway > is just a pipe, and a pipe is just a file with scrolling-window > state over time. > > The IETF could give every form of implementation a different > type and every type its own set of methods for manipulating > state, but all that will accomplish is the death of another > protocol. And no, I don't care what SOAP does via POST, > since SOAP has already proven to be a miserable failure. OK, so that sounds to me like resources should fall into distinct categories: (A1) Collections vs (A2) Non-Collections (B1) Put-able vs (B2) Non-Put-able - resources of type A1 would understand POST request as having "ADDMEMBER" semantics - resources of type A2 can (within reason) do anything they like with POST (as long as compliant to RFC2616) - resources of type B1 will allow PUT (as defined by RFC2616) and understand POST as "append" operation Let's consider a simple WebDAV server that supports only resources of types A1 and B1. What's the recommendation to do authoring operations beyond PUT on these resources? Define new methods (such as VERSION-CONTROL) or mint new related URLs to which existing methods can be applied? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MJO7aZ004222 for ; Tue, 22 Feb 2005 11:24:07 -0800 Received: (qmail invoked by alias); 22 Feb 2005 19:24:00 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp015) with SMTP; 22 Feb 2005 20:24:00 +0100 X-Authenticated: #1915285 Message-ID: <421B86CC.7020402@gmx.de> Date: Tue, 22 Feb 2005 20:23:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier References: <20050221213247.GB8870@mail.shareable.org> <421B6778.1080804@gmx.de> <20050222190228.GD22555@mail.shareable.org> In-Reply-To: <20050222190228.GD22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Geoffrey M Clemm , HTTP Working Group , WebDAV , CalDAV DevList 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:24:08 -0000 Jamie Lokier wrote: > Julian Reschke wrote: > >>I'm not sure what your point is. Of course if a server mishaves that >>way, a client accessing it may cause problems. But that's the problem of >>the server, and I don't think there's anything we can do about that when >>discussing HTTP based protocols. >> >>What am I missing? > > > You're missing that when you are doing CalDAV* requests, you _know_ the > URL you are accessing is CalDAV compliant already. (* - example). How does a client do *any* kind of server feature discovery if *any* method (including things like OPTIONS) may cause harm because of broken server implementations? > If you don't know that you have big problems. Such as? > So you don't need new methods just to express "intent". > (Maybe for other reasons, but not this one). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MJJUaZ004017 for ; Tue, 22 Feb 2005 11:19:31 -0800 Received: (qmail invoked by alias); 22 Feb 2005 19:19:24 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp022) with SMTP; 22 Feb 2005 20:19:24 +0100 X-Authenticated: #1915285 Message-ID: <421B85B7.7040405@gmx.de> Date: Tue, 22 Feb 2005 20:19:19 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:19:36 -0000 Roy T. Fielding wrote: > ... >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, >> and report that in the Location response header >> (> -00.html#rfc.section.A.2>). > > > That is not allowed in HTTP. Thanks for the clarification. >> 2) Atom's approach is to use service URIs to which the client can >> POST, and to discover these service URIs by parting entity (feed) >> bodies. > > > That is allowed. Sure. I didn't mean to imply otherwise. >> Somehow I have the (perhaps naive) wish that identical requirements >> should lead to common protocol constructs. >> >> 1) Seems to break PUT semantics; >> >> 2) Is specific to Atom and not applicable to other protocols. > > > No, it isn't. The client must "discover" the server's URI somehow, > whether that be via hypertext, save under dialogs, or an atom link. > They are all equivalent discovery mechanisms. When Atom does a POST > it will send a representation of an entry (which happens to be just > another resource). When a generic HTTP client does a POST it will > send a representation of a resource. > > The server receives a POST message targeting a URI and containing > a representation. It can do one of three things: 1) deny the request > with method not allowed (or any other error); 2) treat all POSTs > as the same; or 3) decide, based on the URI alone or in combination > with the representation, how to process the request. > > In all cases, the client can assume the addmember semantics of POST > without any interoperability issues. It is the server's responsibility > to provide resource references to the client that match the actions > called for by whatever it is the client is doing, and even if the > client picks some random URI the server is more than capable of > providing an appropriate response. > > Geoff asked what happens if the resource already supports POST > for some other purpose. The answer is one of > > 1) if the implementation supports the addmember purpose > in addition to its other duties, it will return 201 Created; How is it (the resource) supposed to distinguish? > 2) if the implementation does not allow subsidiary resources > to be created, then > > a) if the implementation is written according to HTTP, > it will return 415 Unsupported Media Type; or > > b) if the implementation is clueless, it will attempt to > parse the media type that it expects and will fail with > some form of 4xx response. [Note that this is the case > whether the method is POST or ADDMEMBER -- clueless > implementations do not check the method either.] > > c) if the implementation is totally ignorant of all things > HTTP, it will respond with 200 and a friendly error message > about how this site only works with MSIE 5 (again, > regardless of the method used). > > So, the answer to Geoff's question is a new method is not necessary > to distinguish one POST from another POST because this was already > considered by HTTP in 1992 > > http://www.w3.org/Protocols/HTTP/Methods/Post.html > > and codified in RFC 1945, 2068, and 2616. The reason it allows > the server so much leeway in its handling of the request is because > only the resource can determine, according to its own implementation > and purpose in life, the most appropriate way to store subsidiary > resources. ANY other specification would assume that an HTTP > server is just another form of file server like FTP (which is not > its purpose in life, as I've explained a million times before). > > If the client sends random unsafe requests to a Web server, > it will obtain randomly unsafe results regardless of the method > used. If the server provides a URI as an authorable resource, > then POST to a collection has the semantics of adding a member > to that collection -- the semantics have not changed just because > webdav chose to ignore that feature of HTTP. I still have a hard time understanding what to learn from this. It seems that we're now discussing "when to define new HTTP methods" which is definitively an interesting topic... 1) If I understand you correctly, WebDAV should have said that POST to a WebDAV collection resource indeed is the operation I called ADDMEMBER. RFC2518 says in : "Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus the semantics of POST are unmodified when applied to a collection." It would be interesting to find out how the working group came to that decision (I don't remember seeing that discussion when I went through the archives some time ago; but I may have missed it). 2) RFC2518 introduces WebDAV collections as a new resource type (with a distinct creation method, MKCOL). How would a client use the POST method (as described above) to create a new collection then? In WebDAV, the only difference between a collection and a non-collection resource is containment; thus a WebDAV collection may respond to GET with any content type the server likes. 3) RFC3253 (DeltaV) defines "VERSION-CONTROL", which is a well-defined operation that puts a resource under version control (and may be applied to WebDAV collections as well). Of course that operation *could* have been defined using POST, but assuming POST to a WebDAV collection is the same as ADDMEMBER, how could I possible use POST to do something else then? So should RFC3253 have used POST instead? If the answer is "yes", how should it have resolved the conflict between the two differing semantics that are needed? If the solution is to use different URLs for POST, what would have been a good way to discover these URLs? Wondering, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1MJ2haa032450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 11:02: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 j1MJ2U81025501; Tue, 22 Feb 2005 19:02:30 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1MJ2SOE025499; Tue, 22 Feb 2005 19:02:28 GMT Date: Tue, 22 Feb 2005 19:02:28 +0000 From: Jamie Lokier To: Julian Reschke Message-ID: <20050222190228.GD22555@mail.shareable.org> References: <20050221213247.GB8870@mail.shareable.org> <421B6778.1080804@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421B6778.1080804@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 , HTTP Working Group , WebDAV , CalDAV DevList 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:02:45 -0000 Julian Reschke wrote: > I'm not sure what your point is. Of course if a server mishaves that > way, a client accessing it may cause problems. But that's the problem of > the server, and I don't think there's anything we can do about that when > discussing HTTP based protocols. > > What am I missing? You're missing that when you are doing CalDAV* requests, you _know_ the URL you are accessing is CalDAV compliant already. (* - example). If you don't know that you have big problems. So you don't need new methods just to express "intent". (Maybe for other reasons, but not this one). -- Jamie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MIxvaZ032011 for ; Tue, 22 Feb 2005 10:59:57 -0800 Received: (qmail invoked by alias); 22 Feb 2005 18:59:51 -0000 Received: from pD9E62405.dip.t-dialin.net (EHLO [192.168.0.3]) (217.230.36.5) by mail.gmx.net (mp018) with SMTP; 22 Feb 2005 19:59:51 +0100 X-Authenticated: #1915285 Message-ID: <421B811D.2000202@gmx.de> Date: Tue, 22 Feb 2005 19:59:41 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier References: <20050222161520.GA22555@mail.shareable.org> <200502221838.j1MIc451030030@wera.hpl.hp.com> <20050222185642.GC22555@mail.shareable.org> In-Reply-To: <20050222185642.GC22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: HTTP Working Group , WebDAV , CalDAV DevList , Jeffrey Mogul 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 18:59:59 -0000 Jamie Lokier wrote: > Jeffrey Mogul wrote: > >>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. > > > I'm arguing _against_ adding a new method. :-) On the other hand, arguing against new methods by principle may be a recipe for doom as well. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: Jeff.Mogul@hp.com X-Envelope-To: 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 j1MIxtaa032012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Feb 2005 10:59:55 -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 EC6CF1045F; Tue, 22 Feb 2005 10:59:54 -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 j1MIxroo023669; Tue, 22 Feb 2005 10:59:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.10/8.12.9) with SMTP id j1MIxq51030488; Tue, 22 Feb 2005 10:59:52 -0800 (PST) From: Jeffrey Mogul Message-Id: <200502221859.j1MIxq51030488@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: Jamie Lokier In-reply-to: Your message of "Tue, 22 Feb 2005 18:56:42 GMT." <20050222185642.GC22555@mail.shareable.org> X-Organization: Hewlett-Packard Labs, Large Scale Systems group Date: Tue, 22 Feb 2005 10:59:52 -0800 X-Mts: smtp X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , CalDAV DevList , HTTP Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 18:59:55 -0000 > 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. I'm arguing _against_ adding a new method. Sorry! ... I guess I lost track of the thread at some point! I still don't accept the "don't use OPTIONS" line of argument. (If I got that part right.) -Jeff X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1MIuuaa031576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 10:56:57 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1MIug81025328; Tue, 22 Feb 2005 18:56:42 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1MIugxK025326; Tue, 22 Feb 2005 18:56:42 GMT Date: Tue, 22 Feb 2005 18:56:42 +0000 From: Jamie Lokier To: Jeffrey Mogul Message-ID: <20050222185642.GC22555@mail.shareable.org> References: <20050222161520.GA22555@mail.shareable.org> <200502221838.j1MIc451030030@wera.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502221838.j1MIc451030030@wera.hpl.hp.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , CalDAV DevList , HTTP Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 18:56:58 -0000 Jeffrey Mogul wrote: > 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. I'm arguing _against_ adding a new method. -- Jamie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MIqOaZ030952 for ; Tue, 22 Feb 2005 10:52:24 -0800 Received: (qmail invoked by alias); 22 Feb 2005 18:52:18 -0000 Received: from pD9FF0736.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.7.54) by mail.gmx.net (mp003) with SMTP; 22 Feb 2005 19:52:18 +0100 X-Authenticated: #1915285 Message-ID: <421B7F59.5080702@gmx.de> Date: Tue, 22 Feb 2005 19:52:09 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> <1109097394.6051.1.camel@sukothai.pingtel.com> In-Reply-To: <1109097394.6051.1.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Geoffrey M Clemm , HTTP Working Group , Jamie Lokier , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 18:52:27 -0000 Scott Lawrence wrote: > On Tue, 2005-02-22 at 17:36 +0100, Julian Reschke wrote: > >>So what do I do if a have a resource that accepts HTML form posts, >>SOAP >>requests and ADDMEMBER-like semantics on the same URL? > > > Either: > > - Implement it very very carefully. Hm. What exactly does that mean? When POST is applied to that resource with a content type of "application/soap+xml", is it supposed to store the attached entity as a new resource (with content type "application/soap+xml", returning a Location response header with the URL of the new resource), or should it process it according to ? > or > > - Change your server organization so that they use different URLs. > >>>The only technical reason why a new method would be required in HTTP >>>is if the message semantics were different. For example, POST is >> >>Of course. That's why they are defined to be different from POST. > > > But that's just the point - from the perspective of HTTP, the proposed > ADDMEMBER is not fundamentally different from POST. No, it's a subset, thus it can not be "fundamentelly different". That's on purpose. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: Jeff.Mogul@hp.com X-Envelope-To: 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 ; 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 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 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 , CalDAV DevList , HTTP Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 X-Envelope-From: scott@skrb.org X-Envelope-To: Received: from mail.pingtel.com (user3.pingtel.com [65.220.123.3] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1MIaZaZ029654 for ; Tue, 22 Feb 2005 10:36:36 -0800 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id C901E6C01E; Tue, 22 Feb 2005 13:36:34 -0500 (EST) Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 From: Scott Lawrence To: Julian Reschke In-Reply-To: <421B5F72.6070806@gmx.de> References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> <421B5F72.6070806@gmx.de> Content-Type: text/plain Organization: http://skrb.org/scott/ Date: Tue, 22 Feb 2005 13:36:34 -0500 Message-Id: <1109097394.6051.1.camel@sukothai.pingtel.com> 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 Cc: Geoffrey M Clemm , HTTP Working Group , Jamie Lokier , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 18:36:36 -0000 On Tue, 2005-02-22 at 17:36 +0100, Julian Reschke wrote: > > So what do I do if a have a resource that accepts HTML form posts, > SOAP > requests and ADDMEMBER-like semantics on the same URL? Either: - Implement it very very carefully. or - Change your server organization so that they use different URLs. > > The only technical reason why a new method would be required in HTTP > > is if the message semantics were different. For example, POST is > > Of course. That's why they are defined to be different from POST. But that's just the point - from the perspective of HTTP, the proposed ADDMEMBER is not fundamentally different from POST. X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MHAOaZ017029 for ; Tue, 22 Feb 2005 09:10:25 -0800 Received: (qmail invoked by alias); 22 Feb 2005 17:10:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp024) with SMTP; 22 Feb 2005 18:10:19 +0100 X-Authenticated: #1915285 Message-ID: <421B6778.1080804@gmx.de> Date: Tue, 22 Feb 2005 18:10:16 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier References: <20050221213247.GB8870@mail.shareable.org> In-Reply-To: <20050221213247.GB8870@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Geoffrey M Clemm , HTTP Working Group , WebDAV , CalDAV DevList 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 17:10:32 -0000 Jamie Lokier wrote: > Geoffrey M Clemm wrote: > >> My main concern is that because of the popularity of SOAP, >> many/most implementations fall into category 2b (i.e., "clueless"), >> so a resource will say that it supports the POST operation, >> but will actually fail it with some kind of 4xx response >> because it cannot parse the body, or in the worst case, >> will successfully parse the body and execute some potentially >> harmful SOAP operation that was never intended by the client >> (the client just wanted a subsidiary whose content was that body >> to be created). > > .. > >> I'm rather surprised that clueless (e.g., SOAP :-) implementations >> would parse the body of an unknown method (e.g., ADDMEMBER) >> and treat it as if it were a POST call. > > > Yes... I have seen numerous CGI implementations which parse a request > as GET or POST, even if it has another method. > > >> But even if a clueless implementation will try to parse the >> body of an unknown method like ADDMEMBER, I assume it is very >> unlikely that it would say that it supports the ADDMEMBER >> method on that resource, so that at least would give the client >> a way of avoiding the problem (i.e., by first asking the resource >> if it supports the ADDMEMBER function, before attempting it). > > > I think that's a reasonable assumption. > > But you should always try to avoid accessing unknown resources, even > to query their capabilities: There are implementations where sending > OPTIONS to them will be interpreted as a POST or stateful GET :) Jamie, I'm not sure what your point is. Of course if a server mishaves that way, a client accessing it may cause problems. But that's the problem of the server, and I don't think there's anything we can do about that when discussing HTTP based protocols. What am I missing? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MGuraZ016429 for ; Tue, 22 Feb 2005 08:56:53 -0800 Received: (qmail invoked by alias); 22 Feb 2005 16:56:46 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp008) with SMTP; 22 Feb 2005 17:56:46 +0100 X-Authenticated: #1915285 Message-ID: <421B644C.4020806@gmx.de> Date: Tue, 22 Feb 2005 17:56:44 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> In-Reply-To: <1109040989.3811.39.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 16:56:55 -0000 Scott Lawrence wrote: > On Mon, 2005-02-21 at 21:28 +0000, Jamie Lokier wrote: > >>Scott Lawrence wrote: >> >>>>In which case I couldn't use the content-type of my actual request body >>>>for the Content-Type request header, right? >>> >>>I fear that I may have lost the thread of your comment... you cannot use >>>Content-Type to send anything _but_ the content type of your request >>>body. >> >>Roy said that POST can take into account the request content type to >>decide the action that is taken. >> >>I believe Julian wants to "create resource" with an arbitrary content >>type - _without_ the content type having any effect on the action that >>is taken to create the resource. > > > But setting the content type of the resulting resource _is_ having an > effect !?! > > The point that I think Roy and I have both failed to communicate is > this: POST does not in itself define what happens - the thing to which > the request is POSTed (identified by the full URL) makes that decision. Well :-) I certainly am aware of that fact. That's the *reason* of proposing an alternate method that has strict semantics instead. > That thing is free to use the URL, the content body, the time of day, > the phase of the moon, or whatever it wants to when deciding what to do > with the resource _and_you_get_to_choose_ because you are creating that > thing. If you want to define how you use POST in such a way that you > say that the Content-Type of the body should be preserved in the new > resource you are adding to the server, that's fine. If you want to post > an entity body in the request that encapsulates metadata about the > resource with the resource itself (as is done in rfc1867 form file > upload), that's fine too. You already have what you need in POST - > defining a new method does not add any new capability - it just adds > ambiguity for the servers that don't know what it is (all intermediate > systems already know that POST is not idempotent and the response to it > can only be cached if the response so indicates - that's all you need). I am fully aware that the desired semantics *can* be achieved with a well-defined message used with POST. The issue is that if multiple protocols (such as Caldav or Atompub) want to use the same semantics, it would be nice if they could use the same format, so that general purpose servers can take advantage of that. Whether that is some specific kind of POST, ADDMEMBER or PUT+Redirect (already dissed by Roy :-) is a separate issue here. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MGngaZ016157 for ; Tue, 22 Feb 2005 08:49:43 -0800 Received: (qmail invoked by alias); 22 Feb 2005 16:49:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp023) with SMTP; 22 Feb 2005 17:49:36 +0100 X-Authenticated: #1915285 Message-ID: <421B629E.4090303@gmx.de> Date: Tue, 22 Feb 2005 17:49:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <421A56A8.20905@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 16:49:44 -0000 Roy T. Fielding wrote: > > On Feb 21, 2005, at 1:46 PM, Julian Reschke wrote: > >> Jamie Lokier wrote: >> >>> I believe Julian wants to "create resource" with an arbitrary content >>> type - _without_ the content type having any effect on the action that >>> is taken to create the resource. >> >> >> Correct. > > > General-purpose HTTP servers will not allow that for security > reasons. They use the media type internally as an extensibility > mechanism. Yes. But I'm not speaking of general-purpose servers, but of servers that *do* want to allow that (just like every off-the-shelf WebDAV server). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1MGaBaZ014740 for ; Tue, 22 Feb 2005 08:36:12 -0800 Received: (qmail invoked by alias); 22 Feb 2005 16:36:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.87]) (217.5.201.10) by mail.gmx.net (mp028) with SMTP; 22 Feb 2005 17:36:05 +0100 X-Authenticated: #1915285 Message-ID: <421B5F72.6070806@gmx.de> Date: Tue, 22 Feb 2005 17:36:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] Re: draft-reschke-http-addmember-00 References: <20050221213247.GB8870@mail.shareable.org> <20050222161520.GA22555@mail.shareable.org> In-Reply-To: <20050222161520.GA22555@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Geoffrey M Clemm , HTTP Working Group , WebDAV , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 16:36:14 -0000 Jamie Lokier wrote: > Geoffrey M Clemm wrote: > >> > But you should always try to avoid accessing unknown resources, even >> > to query their capabilities: There are implementations where >> sending >> > OPTIONS to them will be interpreted as a POST or stateful GET :) >> >> I'm not sure what you mean by "avoid accessing unknown resources". >> The only way a client "knows" about a resource is by doing some >> discovery method on it such as OPTIONS. > > > No: the way a client knows about a resource is that something asks the > client to access the resource. > > 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. > 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). > 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. See above. > 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. > This is why the client has to assume the user gave it a URL with known > behaviour in the first place. > > This is why a client whose job is "add a member to a collection" may > _assume_ that it's ok to use POST for this, if POST is specified as > having the right behaviour _on that resource_. So what do I do if a have a resource that accepts HTML form posts, SOAP requests and ADDMEMBER-like semantics on the same URL? > The only technical reason why a new method would be required in HTTP > is if the message semantics were different. For example, POST is Of course. That's why they are defined to be different from POST. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1MGFQaa013327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 08:15:28 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1MGFM81023034; Tue, 22 Feb 2005 16:15:22 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1MGFLMh023032; Tue, 22 Feb 2005 16:15:21 GMT Date: Tue, 22 Feb 2005 16:15:21 +0000 From: Jamie Lokier To: Geoffrey M Clemm Message-ID: <20050222161520.GA22555@mail.shareable.org> References: <20050221213247.GB8870@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , CalDAV DevList , HTTP Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 16:15:29 -0000 Geoffrey M Clemm wrote: > > But you should always try to avoid accessing unknown resources, even > > to query their capabilities: There are implementations where > sending > > OPTIONS to them will be interpreted as a POST or stateful GET :) > > I'm not sure what you mean by "avoid accessing unknown resources". > The only way a client "knows" about a resource is by doing some > discovery method on it such as OPTIONS. No: the way a client knows about a resource is that something asks the client to access the resource. 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. 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. 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. 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. This is why the client has to assume the user gave it a URL with known behaviour in the first place. This is why a client whose job is "add a member to a collection" may _assume_ that it's ok to use POST for this, if POST is specified as having the right behaviour _on that resource_. The only technical reason why a new method would be required in HTTP is if the message semantics were different. For example, POST is allowed to return 201 with Location; PUT is not. Proxies and caches may already understand this. From a purely technical view (not counting "intention") that's what makes POST appropriate. The addition of a new method does not add anything technical, it only expresses "intention". Whereas the methods GET, POST, DELETE, TRACE etc. _do_ have technical differences in terms of what HTTP messages are expected. That's why they exist. -- Jamie X-Envelope-From: distobj@acm.org X-Envelope-To: Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1MDcaaZ014853 for ; Tue, 22 Feb 2005 05:38:36 -0800 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D3aEg-0001BI-00; Tue, 22 Feb 2005 08:37:58 -0500 Date: Tue, 22 Feb 2005 08:37:58 -0500 From: Mark Baker To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050222133758.GD4504@markbaker.ca> References: <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 13:38:38 -0000 On Tue, Feb 22, 2005 at 12:21:05AM -0800, Roy T. Fielding wrote: > >IMO, it's because there are advantages to having messages which reflect > >the expectations of their sender. > > Umm, think about that sentence and you will find it has no content. > Messages reflect the instruction of the sender. POST does that. > > What you are really saying is that there are advantages to the > client knowing the nature of a resource, [lots of other stuff that I agree with snipped] Ah, so you're saying that ADDMEMBER isn't uniform? Sorry, I wasn't able to extract that from your other messages. But can you please explain your reasoning behind that belief? From my POV, the draft defines ADDMEMBER semantics to be a small, (seemingly) uniform adjustment upon PUT semantics. Can you give an example of a resource for which ADDMEMBER wouldn't make sense? Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1M8L6aa004113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Feb 2005 00:21:06 -0800 Received: from ip68-4-71-218.oc.oc.cox.net ([68.4.71.218] helo=[192.168.0.100]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3VI2-0005f2-1X; Tue, 22 Feb 2005 00:21:06 -0800 In-Reply-To: <20050222034655.GC4504@markbaker.ca> References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> <20050222034655.GC4504@markbaker.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7d6e31bc68586bba82b76fd4fe4443ba@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Tue, 22 Feb 2005 00:21:05 -0800 To: Mark Baker X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 08:21:08 -0000 On Feb 21, 2005, at 7:46 PM, Mark Baker wrote: > Let me ask this; why do we have PUT when a valid effect of a POST > could also be to set the state of a resource? Because PUT means set the state of this resource, whereas POST does not. > IMO, it's because there are advantages to having messages which reflect > the expectations of their sender. Umm, think about that sentence and you will find it has no content. Messages reflect the instruction of the sender. POST does that. What you are really saying is that there are advantages to the client knowing the nature of a resource, encoding that nature into the set of methods used, and thus forcing how its state will be impacted by each messaged action. That is what Julian wants in an ADDMEMBER method. You, of all people, should be the first to recognize that slippery slope. Yes, it has advantages, but it also has far-reaching disadvantages that HTTP was designed to prevent. It causes clients to become coupled to particular "types" of resources on the server, which is just another from of implementation-dependency. It leads to absolutely moronic implementations that have to test each resource for the set of methods it implements before performing a set of actions that would have the same result as a generic POST. [Which is to say that it will suck every bit as much as the other methods introduced by webdav and its prodigy that created arbitrary resource types for collections, versions, and now calendars.] POST, in contrast, is a generic semantic that allows the resource to determine its implementation-specific effects. POST to a collection means add a member. POST to a PUT-able resource means an atomic append. POST to a messaging gateway means "post this". POST to any other resource means "process this". Note, however, that to a client they all mean the same thing: take this data and apply it in accordance with your nature. The client does not need to know anything more because the client already knows what it wants to do (and knowing more cannot help it, since only the server is allowed to know the implementation). PUT versus PATCH might lead you to an interesting comparison, at least in terms of seeing when two methods do have different semantics. A better example is POST versus PATCH, given that PATCHing a collection could be defined as a set of add/remove operations on the collection state. One could easily define a patch media type for that, but there are also good reasons not to. POST versus ADDMEMBER, however, does not compare at all because POST is already defined to be "add a member." POST only seems to have multiple definitions because the other definitions are examples of various forms of partial state change within a resource that may consist of identifiable subcomponents. It is really just one semantic definition that manifests in different ways based upon how the implementer views the resource to which the POST is applied. A file is just an ordered collection of bytes. A collection is just a file with a compound media type. A gateway is just a pipe, and a pipe is just a file with scrolling-window state over time. The IETF could give every form of implementation a different type and every type its own set of methods for manipulating state, but all that will accomplish is the death of another protocol. And no, I don't care what SOAP does via POST, since SOAP has already proven to be a miserable failure. Cheers, Roy T. Fielding Chief Scientist, Day Software X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet03.oracle.com (rgminet03.oracle.com [148.87.122.32]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1M5S5aa006241 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 21 Feb 2005 21:28:05 -0800 Received: from rgminet03.oracle.com (localhost [127.0.0.1]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1M5RWe4005462; Tue, 22 Feb 2005 00:27:32 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1M5JhAL030322; Tue, 22 Feb 2005 00:22:02 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1M5Jg3J030789; Mon, 21 Feb 2005 22:19:42 -0700 Received: from [192.168.1.200] (dhcp-amer-csvpn-gw1-141-144-65-231.vpn.oracle.com [141.144.65.231]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1M5JNNk030569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 21 Feb 2005 22:19:24 -0700 Message-ID: <421AC0DB.6000001@oracle.com> Date: Tue, 22 Feb 2005 00:19:23 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: WebDAV , HTTP Working Group , CalDAV DevList Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: "Roy T. Fielding" , Mark Baker X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 05:28:07 -0000 Ideally we would have a solution that would work for all methods that may request the creation of a new resource (e.g, LOCK, PUT, COPY, MOVE, MKCOL, MKWORKSPACE, MKACTIVITY, MKCALENDAR, ...). Could the solution be as simple as specifying an empty query component (e.g., "?") in the Request-URI for those methods, and have the methods return the Location header as part of their response? For instance, PUT /calendar/bernard/? would request the server to create a new resource in the collection /calendar/bernard/ and let the server chose the name of the resource. Is there already a defined use for the query component for the methods mentionned above? Cheers, Bernard Cyrus Daboo wrote: > > > > > Hi Julian, > > --On February 17, 2005 2:54:38 PM +0100 Julian Reschke > wrote: > >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, and >> report that in the Location response header >> (> fc.section.A.2>). > > > I want to add that in the CalDAV case this URI naming restriction will > also apply to COPY and MOVE methods too, not just PUT. So we do need to > come up with a solution that at least works with those methods too. Of > course it is possible to emulate COPY and MOVE using PUT (client > downloads original data, creates it in new location) and DELETE (remove > old data in the case of MOVE) - but we should really have the proper > atomic operations for this. > X-Envelope-From: geoffrey.clemm@us.ibm.com X-Envelope-To: Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1M4P5aa032433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Feb 2005 20:25:06 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1M4OxaF014294 for ; Mon, 21 Feb 2005 23:24:59 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1M4Ox0H187818 for ; Mon, 21 Feb 2005 23:24:59 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1M4OxFW007692 for ; Mon, 21 Feb 2005 23:24:59 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1M4Ox1C007689; Mon, 21 Feb 2005 23:24:59 -0500 In-Reply-To: <20050221213247.GB8870@mail.shareable.org> To: Jamie Lokier MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Geoffrey M Clemm Message-ID: Date: Mon, 21 Feb 2005 21:24:50 -0700 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/21/2005 23:24:58, Serialize complete at 02/21/2005 23:24:58 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.431 () DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE Content-Disposition: inline X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , CalDAV DevList , HTTP Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 04:25:09 -0000 Jamie Lokier wrote on 02/21/2005 02:32:47 PM: > Geoffrey M Clemm wrote: > > But even if a clueless implementation will try to parse the > > body of an unknown method like ADDMEMBER, I assume it is very > > unlikely that it would say that it supports the ADDMEMBER > > method on that resource, so that at least would give the client > > a way of avoiding the problem (i.e., by first asking the resource > > if it supports the ADDMEMBER function, before attempting it). > > I think that's a reasonable assumption. > > But you should always try to avoid accessing unknown resources, even > to query their capabilities: There are implementations where sending > OPTIONS to them will be interpreted as a POST or stateful GET :) I'm not sure what you mean by "avoid accessing unknown resources". The only way a client "knows" about a resource is by doing some discovery method on it such as OPTIONS. Cheers, Geoff X-Envelope-From: distobj@acm.org X-Envelope-To: Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1M3qaaZ029749 for ; Mon, 21 Feb 2005 19:52:36 -0800 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D3R0h-0007zY-00; Mon, 21 Feb 2005 22:46:55 -0500 Date: Mon, 21 Feb 2005 22:46:55 -0500 From: Mark Baker To: Scott Lawrence Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050222034655.GC4504@markbaker.ca> References: <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <1109040989.3811.39.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109040989.3811.39.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 03:52:39 -0000 Scott, On Mon, Feb 21, 2005 at 09:56:29PM -0500, Scott Lawrence wrote: > You already have what you need in POST - > defining a new method does not add any new capability Let me ask this; why do we have PUT when a valid effect of a POST could also be to set the state of a resource? IMO, it's because there are advantages to having messages which reflect the expectations of their sender. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca X-Envelope-From: scott@skrb.org X-Envelope-To: Received: from mail.pingtel.com (user3.pingtel.com [65.220.123.3] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1M2uVaZ020285 for ; Mon, 21 Feb 2005 18:56:31 -0800 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 1D0B76C01E; Mon, 21 Feb 2005 21:56:30 -0500 (EST) Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] From: Scott Lawrence To: Jamie Lokier In-Reply-To: <20050221212838.GA8870@mail.shareable.org> References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> Content-Type: text/plain Organization: http://skrb.org/scott/ Date: Mon, 21 Feb 2005 21:56:29 -0500 Message-Id: <1109040989.3811.39.camel@localhost.localdomain> 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 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 02:56:33 -0000 On Mon, 2005-02-21 at 21:28 +0000, Jamie Lokier wrote: > Scott Lawrence wrote: > > > In which case I couldn't use the content-type of my actual request body > > > for the Content-Type request header, right? > > > > I fear that I may have lost the thread of your comment... you cannot use > > Content-Type to send anything _but_ the content type of your request > > body. > > Roy said that POST can take into account the request content type to > decide the action that is taken. > > I believe Julian wants to "create resource" with an arbitrary content > type - _without_ the content type having any effect on the action that > is taken to create the resource. But setting the content type of the resulting resource _is_ having an effect !?! The point that I think Roy and I have both failed to communicate is this: POST does not in itself define what happens - the thing to which the request is POSTed (identified by the full URL) makes that decision. That thing is free to use the URL, the content body, the time of day, the phase of the moon, or whatever it wants to when deciding what to do with the resource _and_you_get_to_choose_ because you are creating that thing. If you want to define how you use POST in such a way that you say that the Content-Type of the body should be preserved in the new resource you are adding to the server, that's fine. If you want to post an entity body in the request that encapsulates metadata about the resource with the resource itself (as is done in rfc1867 form file upload), that's fine too. You already have what you need in POST - defining a new method does not add any new capability - it just adds ambiguity for the servers that don't know what it is (all intermediate systems already know that POST is not idempotent and the response to it can only be cached if the response so indicates - that's all you need). X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1M0Ynaa002792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2005 16:34:50 -0800 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D3O0m-00085Q-0k; Mon, 21 Feb 2005 16:34:48 -0800 In-Reply-To: <421A56A8.20905@gmx.de> References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> <421A56A8.20905@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Mon, 21 Feb 2005 16:34:48 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV WG , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 00:34:52 -0000 On Feb 21, 2005, at 1:46 PM, Julian Reschke wrote: > Jamie Lokier wrote: >> I believe Julian wants to "create resource" with an arbitrary content >> type - _without_ the content type having any effect on the action that >> is taken to create the resource. > > Correct. General-purpose HTTP servers will not allow that for security reasons. They use the media type internally as an extensibility mechanism. ....Roy X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1LLkWaZ016137 for ; Mon, 21 Feb 2005 13:46:33 -0800 Received: (qmail invoked by alias); 21 Feb 2005 21:46:26 -0000 Received: from pD9FF0736.dip.t-dialin.net (EHLO [192.168.0.3]) (217.255.7.54) by mail.gmx.net (mp022) with SMTP; 21 Feb 2005 22:46:26 +0100 X-Authenticated: #1915285 Message-ID: <421A56A8.20905@gmx.de> Date: Mon, 21 Feb 2005 22:46:16 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> <20050221212838.GA8870@mail.shareable.org> In-Reply-To: <20050221212838.GA8870@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , Scott Lawrence , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 21:46:35 -0000 Jamie Lokier wrote: > Scott Lawrence wrote: > >>>In which case I couldn't use the content-type of my actual request body >>>for the Content-Type request header, right? >> >>I fear that I may have lost the thread of your comment... you cannot use >>Content-Type to send anything _but_ the content type of your request >>body. > > > Roy said that POST can take into account the request content type to > decide the action that is taken. > > I believe Julian wants to "create resource" with an arbitrary content > type - _without_ the content type having any effect on the action that > is taken to create the resource. Correct. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1LLWoaa014980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2005 13:32:51 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1LLWn81009008; Mon, 21 Feb 2005 21:32:49 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1LLWlkg009006; Mon, 21 Feb 2005 21:32:47 GMT Date: Mon, 21 Feb 2005 21:32:47 +0000 From: Jamie Lokier To: Geoffrey M Clemm Message-ID: <20050221213247.GB8870@mail.shareable.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: HTTP Working Group , WebDAV , CalDAV DevList 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 21:32:52 -0000 Geoffrey M Clemm wrote: > My main concern is that because of the popularity of SOAP, > many/most implementations fall into category 2b (i.e., "clueless"), > so a resource will say that it supports the POST operation, > but will actually fail it with some kind of 4xx response > because it cannot parse the body, or in the worst case, > will successfully parse the body and execute some potentially > harmful SOAP operation that was never intended by the client > (the client just wanted a subsidiary whose content was that body > to be created). .. > I'm rather surprised that clueless (e.g., SOAP :-) implementations > would parse the body of an unknown method (e.g., ADDMEMBER) > and treat it as if it were a POST call. Yes... I have seen numerous CGI implementations which parse a request as GET or POST, even if it has another method. > But even if a clueless implementation will try to parse the > body of an unknown method like ADDMEMBER, I assume it is very > unlikely that it would say that it supports the ADDMEMBER > method on that resource, so that at least would give the client > a way of avoiding the problem (i.e., by first asking the resource > if it supports the ADDMEMBER function, before attempting it). I think that's a reasonable assumption. But you should always try to avoid accessing unknown resources, even to query their capabilities: There are implementations where sending OPTIONS to them will be interpreted as a POST or stateful GET :) -- Jamie X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1LLSmaa014689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2005 13:28:50 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1LLSc81008951; Mon, 21 Feb 2005 21:28:38 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1LLScLE008949; Mon, 21 Feb 2005 21:28:38 GMT Date: Mon, 21 Feb 2005 21:28:38 +0000 From: Jamie Lokier To: Scott Lawrence Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050221212838.GA8870@mail.shareable.org> References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> <1109017914.3811.29.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1109017914.3811.29.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 21:28:52 -0000 Scott Lawrence wrote: > > In which case I couldn't use the content-type of my actual request body > > for the Content-Type request header, right? > > I fear that I may have lost the thread of your comment... you cannot use > Content-Type to send anything _but_ the content type of your request > body. Roy said that POST can take into account the request content type to decide the action that is taken. I believe Julian wants to "create resource" with an arbitrary content type - _without_ the content type having any effect on the action that is taken to create the resource. -- Jamie X-Envelope-From: scott@skrb.org X-Envelope-To: Received: from mail.pingtel.com (user3.pingtel.com [65.220.123.3] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1LKVtaZ007589 for ; Mon, 21 Feb 2005 12:31:56 -0800 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id A057B6C01E; Mon, 21 Feb 2005 15:31:54 -0500 (EST) Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] From: Scott Lawrence To: Julian Reschke In-Reply-To: <4214F973.9060404@gmx.de> References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> <4214F973.9060404@gmx.de> Content-Type: text/plain Organization: http://skrb.org/scott/ Date: Mon, 21 Feb 2005 15:31:54 -0500 Message-Id: <1109017914.3811.29.camel@localhost.localdomain> 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 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 20:31:58 -0000 On Thu, 2005-02-17 at 21:07 +0100, Julian Reschke wrote: > Scott Lawrence wrote: > > 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? I fear that I may have lost the thread of your comment... you cannot use Content-Type to send anything _but_ the content type of your request body. > > 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. Then you've been living on a nicer part of the net than I do. I run a server that provides subversion over webdav methods, and it's a routine item to tell people to use ssl to access it so that their proxy won't reject the webdav methods. X-Envelope-From: distobj@acm.org X-Envelope-To: Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1IEhcaZ003914 for ; Fri, 18 Feb 2005 06:43:38 -0800 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D29LL-0002YN-00; Fri, 18 Feb 2005 09:42:55 -0500 Date: Fri, 18 Feb 2005 09:42:55 -0500 From: Mark Baker To: HTTP Working Group , CalDAV DevList Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050218144254.GB4504@markbaker.ca> References: <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 14:43:40 -0000 On Wed, Feb 16, 2005 at 05:45:46PM -0800, Roy T. Fielding wrote: > On Feb 16, 2005, at 4:53 AM, Mark Baker wrote: > >On Tue, Feb 15, 2005 at 03:02:46PM -0800, Roy T. Fielding wrote: > >> > >>This feature of HTTP is already defined as > >> > >> POST + media-type ==> 201 + location > > > >I was thinking the same thing Roy, but a new method would have the > >advantage of improved visibility; an intermediary observing a POST/201 > >interaction wouldn't see anything in the POST request which licensed it > >to interpret that request as an attempt to store state, whereas a new > >method would provide exactly that license. > > POST is always an attempt to store state. I meant "store" in the "file->save" sense of the word, where the resulting state of the server includes *some* resource whose state is represented by the representation included in the request. For PUT, the Request-URI would identify that resource, while for ADDMEMBER, the server would mint a new resource with that state. > >>The media type is more than > >>sufficient to distinguish this action from any other type of > >>misdirected POST, > > > >How so? > > Because the target URI knows what type of collection it is and > how to process POST requests. Right, but it seems to me that operation and media type should be orthogonal. So assuming they aren't would, at best, be limiting the ability of the operation to be used with different media types. > >But even if there was such a limitation, that seems a bit > >kludgy to me; could such an assumption be expected to hold for even the > >foreseeable future? I wouldn't have thought so. > > The media type is not limited in HTTP and it is not equivalent > to data format. The media type tells the recipient how to process > the message given the method semantics. That is why sending the > same data as "text/html" is functionally different from sending it > as "text/plain" -- the two messages have different semantics. Understood. I've championed that position before, in fact. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca X-Envelope-From: geoffrey.clemm@us.ibm.com X-Envelope-To: Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1I5Awaa017883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 17 Feb 2005 21:10:59 -0800 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1I5Ar38002906 for ; Fri, 18 Feb 2005 00:10:53 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1I5Ar2O267566 for ; Fri, 18 Feb 2005 00:10:53 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1I5AqYL029026 for ; Fri, 18 Feb 2005 00:10:52 -0500 Received: from d01ml261.pok.ibm.com (d01ml261.pok.ibm.com [9.56.227.97]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1I5AqeD029023; Fri, 18 Feb 2005 00:10:52 -0500 In-Reply-To: To: WebDAV MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Geoffrey M Clemm Date: Fri, 18 Feb 2005 00:10:51 -0500 X-MIMETrack: Serialize by Router on D01ML261/01/M/IBM(Release 6.53HF103 | November 15, 2004) at 02/18/2005 00:10:52, Serialize complete at 02/18/2005 00:10:52 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.431 () DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE Content-Disposition: inline X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Fri, 18 Feb 2005 08:35:41 -0800 Cc: CalDAV DevList , HTTP Working Group 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2005 05:11:01 -0000 My main concern is that because of the popularity of SOAP, many/most implementations fall into category 2b (i.e., "clueless"), so a resource will say that it supports the POST operation, but will actually fail it with some kind of 4xx response because it cannot parse the body, or in the worst case, will successfully parse the body and execute some potentially harmful SOAP operation that was never intended by the client (the client just wanted a subsidiary whose content was that body to be created). I'm rather surprised that clueless (e.g., SOAP :-) implementations would parse the body of an unknown method (e.g., ADDMEMBER) and treat it as if it were a POST call. I would have expected SOAP implementations to limit themselves to parsing only POST bodies. But Roy knows way more about that kind of thing than I do ... But even if a clueless implementation will try to parse the body of an unknown method like ADDMEMBER, I assume it is very unlikely that it would say that it supports the ADDMEMBER method on that resource, so that at least would give the client a way of avoiding the problem (i.e., by first asking the resource if it supports the ADDMEMBER function, before attempting it). Cheers, Geoff Roy wrote on 02/17/2005 06:50:39 PM: > > Geoff asked what happens if the resource already supports POST > for some other purpose. The answer is one of > > 1) if the implementation supports the addmember purpose > in addition to its other duties, it will return 201 Created; > > 2) if the implementation does not allow subsidiary resources > to be created, then > > a) if the implementation is written according to HTTP, > it will return 415 Unsupported Media Type; or > > b) if the implementation is clueless, it will attempt to > parse the media type that it expects and will fail with > some form of 4xx response. [Note that this is the case > whether the method is POST or ADDMEMBER -- clueless > implementations do not check the method either.] > > c) if the implementation is totally ignorant of all things > HTTP, it will respond with 200 and a friendly error message > about how this site only works with MSIE 5 (again, > regardless of the method used). > > So, the answer to Geoff's question is a new method is not necessary > to distinguish one POST from another POST because this was already > considered by HTTP in 1992 > > http://www.w3.org/Protocols/HTTP/Methods/Post.html > > and codified in RFC 1945, 2068, and 2616. The reason it allows > the server so much leeway in its handling of the request is because > only the resource can determine, according to its own implementation > and purpose in life, the most appropriate way to store subsidiary > resources. ANY other specification would assume that an HTTP > server is just another form of file server like FTP (which is not > its purpose in life, as I've explained a million times before). > > If the client sends random unsafe requests to a Web server, > it will obtain randomly unsafe results regardless of the method > used. If the server provides a URI as an authorable resource, > then POST to a collection has the semantics of adding a member > to that collection -- the semantics have not changed just because > webdav chose to ignore that feature of HTTP. > > ....Roy > > X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HNoeaa028774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 15:50:41 -0800 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D1vPp-0000F6-Cr; Thu, 17 Feb 2005 15:50:37 -0800 In-Reply-To: <4214A21E.5070804@gmx.de> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Thu, 17 Feb 2005 15:50:39 -0800 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 23:50:43 -0000 On Feb 17, 2005, at 5:54 AM, Julian Reschke wrote: >>> Had HTTP a means for extending a method to declare this additional >>> expectation (as described in the draft's A.3 using RFC 2774), I agree >>> that POST + extension would be appropriate. >> It doesn't because it never needed it. > > OK, let's step back and look at the situation that caused me to make > this proposal. > > Two separate communities (CalDAV/GroupDav and Atompub) encountered the > same issue: what's the best way to create a new resource on an HTTP > server when I can't use PUT as the URI space may be entirely > server-controlled? > > 1) CalDav's approach is: use PUT to an arbitrary member URI of the > container; then let the server automagically move it somewhere else, > and report that in the Location response header > ( -00.html#rfc.section.A.2>). That is not allowed in HTTP. > 2) Atom's approach is to use service URIs to which the client can > POST, and to discover these service URIs by parting entity (feed) > bodies. That is allowed. > Somehow I have the (perhaps naive) wish that identical requirements > should lead to common protocol constructs. > > 1) Seems to break PUT semantics; > > 2) Is specific to Atom and not applicable to other protocols. No, it isn't. The client must "discover" the server's URI somehow, whether that be via hypertext, save under dialogs, or an atom link. They are all equivalent discovery mechanisms. When Atom does a POST it will send a representation of an entry (which happens to be just another resource). When a generic HTTP client does a POST it will send a representation of a resource. The server receives a POST message targeting a URI and containing a representation. It can do one of three things: 1) deny the request with method not allowed (or any other error); 2) treat all POSTs as the same; or 3) decide, based on the URI alone or in combination with the representation, how to process the request. In all cases, the client can assume the addmember semantics of POST without any interoperability issues. It is the server's responsibility to provide resource references to the client that match the actions called for by whatever it is the client is doing, and even if the client picks some random URI the server is more than capable of providing an appropriate response. Geoff asked what happens if the resource already supports POST for some other purpose. The answer is one of 1) if the implementation supports the addmember purpose in addition to its other duties, it will return 201 Created; 2) if the implementation does not allow subsidiary resources to be created, then a) if the implementation is written according to HTTP, it will return 415 Unsupported Media Type; or b) if the implementation is clueless, it will attempt to parse the media type that it expects and will fail with some form of 4xx response. [Note that this is the case whether the method is POST or ADDMEMBER -- clueless implementations do not check the method either.] c) if the implementation is totally ignorant of all things HTTP, it will respond with 200 and a friendly error message about how this site only works with MSIE 5 (again, regardless of the method used). So, the answer to Geoff's question is a new method is not necessary to distinguish one POST from another POST because this was already considered by HTTP in 1992 http://www.w3.org/Protocols/HTTP/Methods/Post.html and codified in RFC 1945, 2068, and 2616. The reason it allows the server so much leeway in its handling of the request is because only the resource can determine, according to its own implementation and purpose in life, the most appropriate way to store subsidiary resources. ANY other specification would assume that an HTTP server is just another form of file server like FTP (which is not its purpose in life, as I've explained a million times before). If the client sends random unsafe requests to a Web server, it will obtain randomly unsafe results regardless of the method used. If the server provides a URI as an authorable resource, then POST to a collection has the semantics of adding a member to that collection -- the semantics have not changed just because webdav chose to ignore that feature of HTTP. ....Roy X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HN6EaZ023626 for ; Thu, 17 Feb 2005 15:06:15 -0800 Received: (qmail invoked by alias); 17 Feb 2005 23:06:08 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp001) with SMTP; 18 Feb 2005 00:06:08 +0100 X-Authenticated: #1915285 Message-ID: <42152354.1090407@gmx.de> Date: Fri, 18 Feb 2005 00:05:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> <4214E6D9.8010706@gmx.de> <20050217201029.GH18275@mail.shareable.org> <4215033B.3000206@gmx.de> <20050217224939.GA22967@mail.shareable.org> In-Reply-To: <20050217224939.GA22967@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , algermissen@acm.org, CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 23:06:17 -0000 Jamie Lokier wrote: > which I took to mean you wanted to be sure of what would happen, > perhaps with a view to a security policy or intermediary behaviour. > My mistake. > > So I'll humbly rephrase my question: > > Even if you do specify ADDMEMBER more tightly (than POST), I still > don't see how the difference would benefit you. You say it is useful > to have an idea what the server will do with a POST, in general. In > general means an arbitrary URI with unknown properties, because if > it's a URI with known properties, you know exactly what POST will do. > > How does specifying ADDMEMBER to have tighter semantics than PUT and > POST benefit you when sending the request to an arbitrary URI with > unknown properties? Can you give an example? The same way as COPY, LOCK, MOVE, VERSION-CONTROL, ... I don't think I understand your point. Any operation *can* be marshalled through POST, but that doesn't mean it's the best way to do it. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HMnoaa021024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 14:49:51 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HMne81023202; Thu, 17 Feb 2005 22:49:40 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HMndaX023200; Thu, 17 Feb 2005 22:49:39 GMT Date: Thu, 17 Feb 2005 22:49:39 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217224939.GA22967@mail.shareable.org> References: <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> <4214E6D9.8010706@gmx.de> <20050217201029.GH18275@mail.shareable.org> <4215033B.3000206@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4215033B.3000206@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , algermissen@acm.org, CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 22:49:52 -0000 Julian Reschke wrote: > OK, to summarize: your point is that PUT doesn't have the strict > semantics (that I claim it has). Let's just agree that we disagree here. Actually I'm saying it isn't implemented with strict semantics in practice. I hope we don't disagree about that ;) Which means there is no point pretending it does have strict semantics for the purpose of access control to an unknown server. > > >That said, even if you do specify ADDMEMBER more tightly, I still > >don't see how the difference would benefit you. You say it could be > >useful to an intermediary, but can you give a plausible example? > > Did I? Ah. It wasn't you who mentioned intermediaries needing to know what the method will do. In response to: >> Why can't you POST to the container resource? >> That's what POST is for, after all. You said this: > Because in general, I will have no idea what the server will do with the > POST. which I took to mean you wanted to be sure of what would happen, perhaps with a view to a security policy or intermediary behaviour. My mistake. So I'll humbly rephrase my question: Even if you do specify ADDMEMBER more tightly (than POST), I still don't see how the difference would benefit you. You say it is useful to have an idea what the server will do with a POST, in general. In general means an arbitrary URI with unknown properties, because if it's a URI with known properties, you know exactly what POST will do. How does specifying ADDMEMBER to have tighter semantics than PUT and POST benefit you when sending the request to an arbitrary URI with unknown properties? Can you give an example? Thanks, -- Jamie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HKnNaZ032369 for ; Thu, 17 Feb 2005 12:49:24 -0800 Received: (qmail invoked by alias); 17 Feb 2005 20:49:16 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp001) with SMTP; 17 Feb 2005 21:49:16 +0100 X-Authenticated: #1915285 Message-ID: <4215033B.3000206@gmx.de> Date: Thu, 17 Feb 2005 21:48:59 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> <4214E6D9.8010706@gmx.de> <20050217201029.GH18275@mail.shareable.org> In-Reply-To: <20050217201029.GH18275@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , algermissen@acm.org, CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 20:49:25 -0000 Jamie Lokier wrote: > ... > And so, for ADDMEMBER to be useful, you need to specify it more > tightly than "PUT except the created resource URI is selected > differently". > > If you do that, it makes sense. If you don't, then ADDMEMBER is no > different from POST. > ... OK, to summarize: your point is that PUT doesn't have the strict semantics (that I claim it has). Let's just agree that we disagree here. > That said, even if you do specify ADDMEMBER more tightly, I still > don't see how the difference would benefit you. You say it could be > useful to an intermediary, but can you give a plausible example? Did I? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HKCIaa028333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 12:12:20 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HKCA81020904; Thu, 17 Feb 2005 20:12:10 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HKCAW6020902; Thu, 17 Feb 2005 20:12:10 GMT Date: Thu, 17 Feb 2005 20:12:10 +0000 From: Jamie Lokier To: Scott Lawrence Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217201210.GI18275@mail.shareable.org> References: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108670449.11773.33.camel@sukothai.pingtel.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 20:12:21 -0000 Scott Lawrence wrote: > 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. Side note: yes, I have to use port 81 to update my web server over WebDAV because the transparent proxy in the way on port 80 blocks DAV methods... -- Jamie X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HKAjaa028214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 12:10:47 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HKAT81020861; Thu, 17 Feb 2005 20:10:29 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HKATnZ020859; Thu, 17 Feb 2005 20:10:29 GMT Date: Thu, 17 Feb 2005 20:10:29 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217201029.GH18275@mail.shareable.org> References: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> <4214E6D9.8010706@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214E6D9.8010706@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , algermissen@acm.org, CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 20:10:48 -0000 Julian Reschke wrote: > >Read section 5.4 "Source Resources and Output Resources" in RFC 2518, > >WebDAV. > >(That part's not specific to WebDAV; it's a just a good explanation). > > In fact, it says: > > "However, if remote editing of the source resource(s) is desired, the > source resource(s) should be given a location in the URI namespace. This > source location should not be one of the locations at which the > generated output is retrievable, since in general it is impossible for > the server to differentiate requests for source resources from requests > for process output resources." Indeed, it's not a requirement though, and people do actually use PUT to update source resources using the output URI space. > >>From the client's point of view, once you have PUT an entity, in > >general you have no way to retrieve that exact entity. Many servers > >will process the resource you created to produce the response to GET, > >instead of merely returning the entity you sent earlier. > > > >Because you can't necessarily retrieve the entity sent, you can't make > >assumptions about what the server stores. It might store only part of > >what you sent, or a transformed version. What it actually stores -- > >and the side effects of doing so -- are quite open. > > You keep saying this, but it would be nice if you could point out where > that kind of behaviour is described. I don't know if it is explicitly described. Section 5.4 of WebDAV seems to come closest. > RFC2616 says: > > "The PUT method requests that the enclosed entity be stored under the > supplied Request-URI." Yes, it's a request, not a SHOULD or MUST. It also doesn't say what the server will actually do with the entity when it's stored URI. As a test, I just tried it on my Apache 2 server with CGI execution enabled. PUT to a .cgi URI overwrites a CGI script; GET runs it and returns the parsed output. That's a fairly standard configuration, and I think that mode of operation is quite widely used too (updating a web site with scripts using PUT). > And that's certainly what today's WebDAV servers implement and WebDAV > clients do expect. Sure, but forget about WebDAV for a moment, I only brought up that document because of the nice text on source and output resources. Real servers do sometimes store the sent entity using PUT, but return a processed output from GET at the same URI -- and people do actually use that feature sometimes. And so you can't have an intermediary _assume_ PUT will stick to the behaviour you think it should - even if we had a consensus that it should. And so, for ADDMEMBER to be useful, you need to specify it more tightly than "PUT except the created resource URI is selected differently". If you do that, it makes sense. If you don't, then ADDMEMBER is no different from POST. That said, even if you do specify ADDMEMBER more tightly, I still don't see how the difference would benefit you. You say it could be useful to an intermediary, but can you give a plausible example? -- Jamie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HK7PaZ027885 for ; Thu, 17 Feb 2005 12:07:25 -0800 Received: (qmail invoked by alias); 17 Feb 2005 20:07:19 -0000 Received: from pD9E510FD.dip.t-dialin.net (EHLO [192.168.0.3]) (217.229.16.253) by mail.gmx.net (mp024) with SMTP; 17 Feb 2005 21:07:19 +0100 X-Authenticated: #1915285 Message-ID: <4214F973.9060404@gmx.de> Date: Thu, 17 Feb 2005 21:07:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> <1108670449.11773.33.camel@sukothai.pingtel.com> In-Reply-To: <1108670449.11773.33.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 20:07:30 -0000 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 -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: scott@skrb.org X-Envelope-To: Received: from mail.pingtel.com (user3.pingtel.com [65.220.123.3] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HK0taZ027030 for ; Thu, 17 Feb 2005 12:00:56 -0800 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id D17426C01C; Thu, 17 Feb 2005 15:00:49 -0500 (EST) Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] From: Scott Lawrence To: Julian Reschke In-Reply-To: <4214E4D0.80408@gmx.de> References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> <4214E4D0.80408@gmx.de> Content-Type: text/plain Organization: http://skrb.org/scott/ Date: Thu, 17 Feb 2005 15:00:49 -0500 Message-Id: <1108670449.11773.33.camel@sukothai.pingtel.com> 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 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 20:01:05 -0000 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. X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HJpeaa025721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 11:51:41 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HJpE81020535; Thu, 17 Feb 2005 19:51:14 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HJpDpm020533; Thu, 17 Feb 2005 19:51:13 GMT Date: Thu, 17 Feb 2005 19:51:13 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217195113.GG18275@mail.shareable.org> References: <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <20050217182505.GA18275@mail.shareable.org> <4214E5B0.8060302@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214E5B0.8060302@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 19:51:43 -0000 Julian Reschke wrote: > >In general, you don't know what it will do with ADDMEMBER either. > > I do, because I'll make the assumption that a server that advertises > support for ADDMEMBER indeed implements what the spec says. Are you > saying that I can't make that assumption? You can define the spec that way of course. It might even be a good idea. :) But then I'd argue it is not the same as "PUT except that the resource is created as a server-selected URI, using the request URI to indicate which container". > >This is better illustrated with PUT. Clearly, PUT is intended for > >creating or modifying an entity at a client-specific URI. > > > >I have the impression you expect this is literally what PUT should do: > >that afterwards, GET from that URI, if permitted, will return the last > >entity that was put. > > Yes. To double check, I just tried it on my Apache 2 server with CGI execution enabled. PUT to a .cgi URI overwrites a CGI script; GET runs it and returns the parsed output. > >Plenty of HTTP servers which don't work like that. Often, you can PUT > >to a URI ending in ".cgi" or ".php" for example, and (possibly > >depending on the put'd content type, possibly not) GET will not return > >the same entity; instead it will initiate processing using the > >resource now present at that URI. > > I'd consider that a bug. Maybe it is a bug (but RFC 2616 doesn't have a SHOULD or MUST, it just says "the PUT method requests..."). But it exists in practice, so it would be foolish for an intermediary doing access control to blindly _assume_ the behaviour you expect based on the method name alone. And if the intermediary has to look at other things like the server name and URI, then POST is adequately specified for this because you can simply define POST to a _known_ URI has having that behaviour. > >You can PUT to a URI ending in ".html" and with content-type > >"text/html" even, but with some servers, GET from the same URI will > >initiate content negotiation and may return that entity, a different > >one, a transcoded one, a tidied one, etc., according to server-defined > >rules. (Section 5.4 of WebDAV, RFC 2518 has more to say on this). > > In which case the server shouldn't have supported PUT on that URI in the > first place. Apache 2 does (assuming authorization); it's what I expected, and it's occasionally even useful. > >Given that PUT has somewhat open-ended semantics - won't ADDMEMBER > >have similarly open-ended semantics? > > I don't agree that it has open-ended semantics. But it's good that you > raise this issue, because it's essential to understand the rational for > ADDMEMBER. Yes. It seems you want an ADDMEMBER which is more tightly specified than just "PUT with server-selected URI". In which case, maybe what you really want is a more tightly specified alternative to PUT with an option for server-selected URI. -- Jamie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HIm0aZ015695 for ; Thu, 17 Feb 2005 10:48:01 -0800 Received: (qmail invoked by alias); 17 Feb 2005 18:47:55 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp016) with SMTP; 17 Feb 2005 19:47:55 +0100 X-Authenticated: #1915285 Message-ID: <4214E6D9.8010706@gmx.de> Date: Thu, 17 Feb 2005 19:47:53 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> <20050217183809.GB18275@mail.shareable.org> In-Reply-To: <20050217183809.GB18275@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , algermissen@acm.org, CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:48:02 -0000 Jamie Lokier wrote: > Julian Reschke wrote: > >>>>Because in general, I will have no idea what the server will do with >>>>the POST. >>> >>>Hmm...the meaning of POST is that the server will process the message. >>>If you receive a 201, >>>the server has created a resource. >> >>But *what* does it contain? In general, I can not assume it will store >>the entity as sent (like PUT). > > ^^^^^^^^ > > You cannot assume PUT will store the entity as sent either. > > Read section 5.4 "Source Resources and Output Resources" in RFC 2518, WebDAV. > (That part's not specific to WebDAV; it's a just a good explanation). In fact, it says: "However, if remote editing of the source resource(s) is desired, the source resource(s) should be given a location in the URI namespace. This source location should not be one of the locations at which the generated output is retrievable, since in general it is impossible for the server to differentiate requests for source resources from requests for process output resources." >>From the client's point of view, once you have PUT an entity, in > general you have no way to retrieve that exact entity. Many servers > will process the resource you created to produce the response to GET, > instead of merely returning the entity you sent earlier. > > Because you can't necessarily retrieve the entity sent, you can't make > assumptions about what the server stores. It might store only part of > what you sent, or a transformed version. What it actually stores -- > and the side effects of doing so -- are quite open. You keep saying this, but it would be nice if you could point out where that kind of behaviour is described. RFC2616 says: "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." And that's certainly what today's WebDAV servers implement and WebDAV clients do expect. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HIh3aZ015207 for ; Thu, 17 Feb 2005 10:43:04 -0800 Received: (qmail invoked by alias); 17 Feb 2005 18:42:58 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp029) with SMTP; 17 Feb 2005 19:42:58 +0100 X-Authenticated: #1915285 Message-ID: <4214E5B0.8060302@gmx.de> Date: Thu, 17 Feb 2005 19:42:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <20050217182505.GA18275@mail.shareable.org> In-Reply-To: <20050217182505.GA18275@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:43:10 -0000 Jamie Lokier wrote: > Julian Reschke wrote: > >>Because in general, I will have no idea what the server will do with the >>POST. > > > In general, you don't know what it will do with ADDMEMBER either. I do, because I'll make the assumption that a server that advertises support for ADDMEMBER indeed implements what the spec says. Are you saying that I can't make that assumption? > This is better illustrated with PUT. Clearly, PUT is intended for > creating or modifying an entity at a client-specific URI. > > I have the impression you expect this is literally what PUT should do: > that afterwards, GET from that URI, if permitted, will return the last > entity that was put. Yes. > Plenty of HTTP servers which don't work like that. Often, you can PUT > to a URI ending in ".cgi" or ".php" for example, and (possibly > depending on the put'd content type, possibly not) GET will not return > the same entity; instead it will initiate processing using the > resource now present at that URI. I'd consider that a bug. > You can PUT to a URI ending in ".html" and with content-type > "text/html" even, but with some servers, GET from the same URI will > initiate content negotiation and may return that entity, a different > one, a transcoded one, a tidied one, etc., according to server-defined > rules. (Section 5.4 of WebDAV, RFC 2518 has more to say on this). In which case the server shouldn't have supported PUT on that URI in the first place. > Given that PUT has somewhat open-ended semantics - won't ADDMEMBER > have similarly open-ended semantics? I don't agree that it has open-ended semantics. But it's good that you raise this issue, because it's essential to understand the rational for ADDMEMBER. > How is an ADDMEMBER whose effect is as open-ended as PUT, but which > creates a resource at a server-selected URI, any different from POST - > even for access control? > > It seems to me that if you're considering making access control > decisions on the difference between ADDMEMBER and POST, then you > should really be making those decisions on the known behaviour of the > request URI. If you don't recognise the request URI, then you don't > really know what ADDMEMMER _or_ POST will do, in general. See above. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HIdKaZ014711 for ; Thu, 17 Feb 2005 10:39:20 -0800 Received: (qmail invoked by alias); 17 Feb 2005 18:39:14 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp007) with SMTP; 17 Feb 2005 19:39:14 +0100 X-Authenticated: #1915285 Message-ID: <4214E4D0.80408@gmx.de> Date: Thu, 17 Feb 2005 19:39:12 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> <1108663634.11773.28.camel@sukothai.pingtel.com> In-Reply-To: <1108663634.11773.28.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:39:24 -0000 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. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HIcFaa014603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 10:38:17 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HIc981019056; Thu, 17 Feb 2005 18:38:09 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HIc9Xd019054; Thu, 17 Feb 2005 18:38:09 GMT Date: Thu, 17 Feb 2005 18:38:09 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217183809.GB18275@mail.shareable.org> References: <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> <4214E092.5040400@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214E092.5040400@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , algermissen@acm.org, CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:38:18 -0000 Julian Reschke wrote: > >>Because in general, I will have no idea what the server will do with > >>the POST. > > > >Hmm...the meaning of POST is that the server will process the message. > >If you receive a 201, > >the server has created a resource. > > But *what* does it contain? In general, I can not assume it will store > the entity as sent (like PUT). ^^^^^^^^ You cannot assume PUT will store the entity as sent either. Read section 5.4 "Source Resources and Output Resources" in RFC 2518, WebDAV. (That part's not specific to WebDAV; it's a just a good explanation). >From the client's point of view, once you have PUT an entity, in general you have no way to retrieve that exact entity. Many servers will process the resource you created to produce the response to GET, instead of merely returning the entity you sent earlier. Because you can't necessarily retrieve the entity sent, you can't make assumptions about what the server stores. It might store only part of what you sent, or a transformed version. What it actually stores -- and the side effects of doing so -- are quite open. -- Jamie X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HIPQaa013586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 10:25:28 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HIP581018874; Thu, 17 Feb 2005 18:25:05 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HIP5Gq018872; Thu, 17 Feb 2005 18:25:05 GMT Date: Thu, 17 Feb 2005 18:25:05 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217182505.GA18275@mail.shareable.org> References: <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214D1E1.9030700@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:25:29 -0000 Julian Reschke wrote: > Because in general, I will have no idea what the server will do with the > POST. In general, you don't know what it will do with ADDMEMBER either. This is better illustrated with PUT. Clearly, PUT is intended for creating or modifying an entity at a client-specific URI. I have the impression you expect this is literally what PUT should do: that afterwards, GET from that URI, if permitted, will return the last entity that was put. Plenty of HTTP servers which don't work like that. Often, you can PUT to a URI ending in ".cgi" or ".php" for example, and (possibly depending on the put'd content type, possibly not) GET will not return the same entity; instead it will initiate processing using the resource now present at that URI. You can PUT to a URI ending in ".html" and with content-type "text/html" even, but with some servers, GET from the same URI will initiate content negotiation and may return that entity, a different one, a transcoded one, a tidied one, etc., according to server-defined rules. (Section 5.4 of WebDAV, RFC 2518 has more to say on this). Given that PUT has somewhat open-ended semantics - won't ADDMEMBER have similarly open-ended semantics? How is an ADDMEMBER whose effect is as open-ended as PUT, but which creates a resource at a server-selected URI, any different from POST - even for access control? It seems to me that if you're considering making access control decisions on the difference between ADDMEMBER and POST, then you should really be making those decisions on the known behaviour of the request URI. If you don't recognise the request URI, then you don't really know what ADDMEMMER _or_ POST will do, in general. -- Jamie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HILFaZ012975 for ; Thu, 17 Feb 2005 10:21:16 -0800 Received: (qmail invoked by alias); 17 Feb 2005 18:21:09 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp025) with SMTP; 17 Feb 2005 19:21:09 +0100 X-Authenticated: #1915285 Message-ID: <4214E092.5040400@gmx.de> Date: Thu, 17 Feb 2005 19:21:06 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: algermissen@acm.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> <4214DD0E.6040709@topicmapping.com> In-Reply-To: <4214DD0E.6040709@topicmapping.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:21:20 -0000 Jan Algermissen wrote: > Julian Reschke wrote > >> Because in general, I will have no idea what the server will do with >> the POST. > > > Hmm...the meaning of POST is that the server will process the message. > If you receive a 201, > the server has created a resource. But *what* does it contain? In general, I can not assume it will store the entity as sent (like PUT). > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: scott@skrb.org X-Envelope-To: Received: from mail.pingtel.com (user3.pingtel.com [65.220.123.3] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HI7FaZ011132 for ; Thu, 17 Feb 2005 10:07:15 -0800 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 028386C01C; Thu, 17 Feb 2005 13:07:15 -0500 (EST) Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] From: Scott Lawrence To: Julian Reschke In-Reply-To: <4214D227.9020607@gmx.de> References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> <4214D227.9020607@gmx.de> Content-Type: text/plain Organization: http://skrb.org/scott/ Date: Thu, 17 Feb 2005 13:07:14 -0500 Message-Id: <1108663634.11773.28.camel@sukothai.pingtel.com> 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: Thu, 17 Feb 2005 10:11:11 -0800 Cc: WebDAV , Mark Baker , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:07:16 -0000 On Thu, 2005-02-17 at 18:19 +0100, Julian Reschke wrote: > > The WebDAV rfc has the following statement in it in Section 5.3 as a > > justification for creating a new method (MKCOL in this case) rather than > > using a special POST operation: > > > >> While the POST method is sufficiently open-ended that a "create a > >> collection" POST command could be constructed, this is undesirable > >> because it would be difficult to separate access control for > >> collection creation from other uses of POST. 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. -- Scott Lawrence http://skrb.org/scott/ X-Envelope-From: jalgermissen@topicmapping.com X-Envelope-To: Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HI6HaZ011007 for ; Thu, 17 Feb 2005 10:06:18 -0800 Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D1q2P-000816-00; Thu, 17 Feb 2005 19:06:05 +0100 Received: from [80.171.116.143] (helo=[10.0.1.2]) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1D1q2P-0001vX-00; Thu, 17 Feb 2005 19:06:05 +0100 Message-ID: <4214DD0E.6040709@topicmapping.com> Date: Thu, 17 Feb 2005 19:06:06 +0100 From: Jan Algermissen User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <4214D1E1.9030700@gmx.de> In-Reply-To: <4214D1E1.9030700@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:9fd5cd4d1b290f5c8d8bf21248da35c6 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Thu, 17 Feb 2005 10:11:11 -0800 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: algermissen@acm.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:06:20 -0000 Julian Reschke wrote > Because in general, I will have no idea what the server will do with > the POST. Hmm...the meaning of POST is that the server will process the message. If you receive a 201, the server has created a resource. What is the use case that does not work with these sementics of POST but that would work with ADDMEMBER? I recall that there was a similar discussion on rest-discuss regarding POST vs QUERY (query having the semantics of 'process query and send 201 to refer to the resource that is the query result). Mark and Roy had a similar exchange like in this thread. I am somewhere in between; I see Mark's point but I lack the in-depth understanding (especially I have no practical experience with the difference). Jan > > Best regards, Julian > -- Jan Algermissen Consultant & Programmer http://jalgermissen.com X-Envelope-From: lisa@osafoundation.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HI35aa010686 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Feb 2005 10:03:06 -0800 In-Reply-To: References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6782df4a8858ea345d3ca814ed91be9d@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Thu, 17 Feb 2005 10:02:58 -0800 To: Cyrus Daboo X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 18:03:09 -0000 I'm beginning to think that for CalDAV, we need some way -- a live property? -- to indicate whether the server will control URL namespace. If we must have this model variation between servers, then at least let the clients discover it. I'm not entirely certain that all clients will require that but I'd put the probability very high that at least some clients will find it very useful at very low cost to the server. Lisa On Feb 17, 2005, at 7:24 AM, Cyrus Daboo wrote: > Hi Julian, > > --On February 17, 2005 2:54:38 PM +0100 Julian Reschke > wrote: > >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, >> and >> report that in the Location response header >> (> -00.html#r >> fc.section.A.2>). > > I want to add that in the CalDAV case this URI naming restriction will > also apply to COPY and MOVE methods too, not just PUT. So we do need > to come up with a solution that at least works with those methods too. > Of course it is possible to emulate COPY and MOVE using PUT (client > downloads original data, creates it in new location) and DELETE > (remove old data in the case of MOVE) - but we should really have the > proper atomic operations for this. > > -- > Cyrus Daboo > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HHJgaZ006460 for ; Thu, 17 Feb 2005 09:19:42 -0800 Received: (qmail invoked by alias); 17 Feb 2005 17:19:36 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp022) with SMTP; 17 Feb 2005 18:19:36 +0100 X-Authenticated: #1915285 Message-ID: <4214D227.9020607@gmx.de> Date: Thu, 17 Feb 2005 18:19:35 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> In-Reply-To: <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , "Roy T. Fielding" , Jamie Lokier , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 17:19:43 -0000 Cyrus Daboo wrote: > Hi Jamie, > > --On February 17, 2005 4:41:42 PM +0000 Jamie Lokier > wrote: > >>> No, it would be the container resource itself. For CalDav, the calendar >>> collection; for Atompub, the feed resource itself. >> >> >> Why can't you POST to the container resource? >> >> That's what POST is for, after all. > > > The WebDAV rfc has the following statement in it in Section 5.3 as a > justification for creating a new method (MKCOL in this case) rather than > using a special POST operation: > >> While the POST method is sufficiently open-ended that a "create a >> collection" POST command could be constructed, this is undesirable >> because it would be difficult to separate access control for >> collection creation from other uses of POST. > > > Wouldn't the same issue be relevant here? > > Interestingly the current WebDAV ACL document does not appear to mention > POST at all - even in the 'Normative' Method Privilege Table in Appendix > B. Is there a reason for that? Yes. As you can do anything with POST, it's impossible to state what privileges you'll need. > Whatever solution we come up with it ideally needs to work seamlessly > with WebDAV ACL. That would be preferrable. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HHIYaZ006348 for ; Thu, 17 Feb 2005 09:18:34 -0800 Received: (qmail invoked by alias); 17 Feb 2005 17:18:27 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp026) with SMTP; 17 Feb 2005 18:18:27 +0100 X-Authenticated: #1915285 Message-ID: <4214D1E1.9030700@gmx.de> Date: Thu, 17 Feb 2005 18:18:25 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> In-Reply-To: <20050217164142.GA17013@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 17:18:37 -0000 Jamie Lokier wrote: > Julian Reschke wrote: > >>>>2) Atom's approach is to use service URIs to which the client can POST, >>>>and to discover these service URIs by parting entity (feed) bodies. >>> >>>... >>> >>> >>>>2) Is specific to Atom and not applicable to other protocols. >>> >>> >>>ADDMEMBER is no different from POST in this respect: >>> >>>You still have to "discover the service URI" to use with ADDMEMBER. >> >>No, it would be the container resource itself. For CalDav, the calendar >>collection; for Atompub, the feed resource itself. > > > Why can't you POST to the container resource? > > That's what POST is for, after all. Because in general, I will have no idea what the server will do with the POST. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HH3kaa004925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 09:03:47 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1HGsD6g024444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2005 11:54:14 -0500 Date: Thu, 17 Feb 2005 12:03:37 -0500 From: Cyrus Daboo To: Jamie Lokier , Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <788C984DF503C81DC332E7DB@ninevah.cyrusoft.com> In-Reply-To: <20050217164142.GA17013@mail.shareable.org> References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> <20050217164142.GA17013@mail.shareable.org> X-Mailer: Mulberry/4.0.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 17:03:50 -0000 Hi Jamie, --On February 17, 2005 4:41:42 PM +0000 Jamie Lokier wrote: >> No, it would be the container resource itself. For CalDav, the calendar >> collection; for Atompub, the feed resource itself. > > Why can't you POST to the container resource? > > That's what POST is for, after all. The WebDAV rfc has the following statement in it in Section 5.3 as a justification for creating a new method (MKCOL in this case) rather than using a special POST operation: > While the POST method is sufficiently open-ended that a "create a > collection" POST command could be constructed, this is undesirable > because it would be difficult to separate access control for > collection creation from other uses of POST. Wouldn't the same issue be relevant here? Interestingly the current WebDAV ACL document does not appear to mention POST at all - even in the 'Normative' Method Privilege Table in Appendix B. Is there a reason for that? Whatever solution we come up with it ideally needs to work seamlessly with WebDAV ACL. -- Cyrus Daboo X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HGnPaa003923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 08:49:26 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1HGdV6g024021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2005 11:39:32 -0500 Date: Thu, 17 Feb 2005 11:48:54 -0500 From: Cyrus Daboo To: Stefan Eissing Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <6C4C37F2896F0D61E21D2C3C@ninevah.cyrusoft.com> In-Reply-To: References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> X-Mailer: Mulberry/4.0.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , HTTP Working Group , "Roy T. Fielding" , CalDAV DevList , WebDAV X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 16:49:28 -0000 Hi Stefan, --On February 17, 2005 5:34:02 PM +0100 Stefan Eissing wrote: > It seems to me that however you solve the PUT/ADDMEMBER/POST problem, it > can be used to solve the MOVE and COPY scenarios as well, at least for > single, plain resources: > > PUT/ADDMEMBER/POST a new, empty resource -> 201 with Location > COPY/MOVE to that new Location > > Would this work? Well, it may be that the server requires some form of valid data to be stored in some location. i.e. a calendar server may refuse to create an empty resource as there has to be some valid calendar data there. That means having to create a 'dummy' resource containing valid but not 'useful' data, then overwrite that with COPY/MOVE. Of course that is ugly, but then we are dealing with an ugly problem anyway, so maybe that is the best we can do. -- Cyrus Daboo X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HGgraa003635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 08:42:56 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HGfh81017030; Thu, 17 Feb 2005 16:41:43 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HGfglK017028; Thu, 17 Feb 2005 16:41:42 GMT Date: Thu, 17 Feb 2005 16:41:42 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217164142.GA17013@mail.shareable.org> References: <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> <4214AE0E.4080202@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214AE0E.4080202@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 16:42:59 -0000 Julian Reschke wrote: > >>2) Atom's approach is to use service URIs to which the client can POST, > >>and to discover these service URIs by parting entity (feed) bodies. > > > >... > > > >>2) Is specific to Atom and not applicable to other protocols. > > > > > >ADDMEMBER is no different from POST in this respect: > > > >You still have to "discover the service URI" to use with ADDMEMBER. > > No, it would be the container resource itself. For CalDav, the calendar > collection; for Atompub, the feed resource itself. Why can't you POST to the container resource? That's what POST is for, after all. -- Jamie X-Envelope-From: stefan.eissing@greenbytes.de X-Envelope-To: Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HGZ7aa003302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 17 Feb 2005 08:35:09 -0800 Received: from [192.168.1.26] by greenbytes.de (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v7.2.3.R) with ESMTP id md50000083833.msg for ; Thu, 17 Feb 2005 17:33:49 +0100 In-Reply-To: References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Eissing Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Thu, 17 Feb 2005 17:34:02 +0100 To: Cyrus Daboo X-Mailer: Apple Mail (2.619.2) X-Authenticated-Sender: se@greenbytes.de X-Spam-Processed: greenbytes.de, Thu, 17 Feb 2005 17:33:49 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.1.26 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: ietf-caldav@osafoundation.org X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Thu, 17 Feb 2005 09:48:41 -0800 Cc: Mark Baker , HTTP Working Group , "Roy T. Fielding" , CalDAV DevList , WebDAV X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 16:35:13 -0000 Am 17.02.2005 um 17:05 schrieb Cyrus Daboo: > Hi Julian, > > --On February 17, 2005 2:54:38 PM +0100 Julian Reschke > wrote: > >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, >> and >> report that in the Location response header >> (> -00.html#r >> fc.section.A.2>). > > I want to add that in the CalDAV case this URI naming restriction will > also apply to COPY and MOVE methods too, not just PUT. So we do need > to come up with a solution that at least works with those methods too. > Of course it is possible to emulate COPY and MOVE using PUT (client > downloads original data, creates it in new location) and DELETE > (remove old data in the case of MOVE) - but we should really have the > proper atomic operations for this. It seems to me that however you solve the PUT/ADDMEMBER/POST problem, it can be used to solve the MOVE and COPY scenarios as well, at least for single, plain resources: PUT/ADDMEMBER/POST a new, empty resource -> 201 with Location COPY/MOVE to that new Location Would this work? //Stefan X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HG5Laa000590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 08:05:22 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1HFtZ6g023042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2005 10:55:37 -0500 Date: Thu, 17 Feb 2005 10:24:32 -0500 From: Cyrus Daboo To: Julian Reschke , "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: In-Reply-To: <4214A21E.5070804@gmx.de> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> X-Mailer: Mulberry/4.0.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , CalDAV DevList , HTTP Working Group X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 16:05:24 -0000 Hi Julian, --On February 17, 2005 2:54:38 PM +0100 Julian Reschke wrote: > 1) CalDav's approach is: use PUT to an arbitrary member URI of the > container; then let the server automagically move it somewhere else, and > report that in the Location response header > ( fc.section.A.2>). I want to add that in the CalDAV case this URI naming restriction will also apply to COPY and MOVE methods too, not just PUT. So we do need to come up with a solution that at least works with those methods too. Of course it is possible to emulate COPY and MOVE using PUT (client downloads original data, creates it in new location) and DELETE (remove old data in the case of MOVE) - but we should really have the proper atomic operations for this. -- Cyrus Daboo X-Envelope-From: joe.gregorio@gmail.com X-Envelope-To: Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1HFRQaZ029568 for ; Thu, 17 Feb 2005 07:27:26 -0800 Received: by rproxy.gmail.com with SMTP id g11so535315rne for ; Thu, 17 Feb 2005 07:27:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=a2WhOPtJMCCAKqXsAlvk2nIfV5RrVxqETRBl/pa4WKmA/bUTUNEq8LpJh/8vHOPIh+IAUHMlD6MSUke41CQvlzYiNlXpGwMDBfDY/7pxOok6ZUq40H5c171TQnjsOUy9DRup0P6fqbsVybuQ0Yfa6FO+KU4KrgowhVYhYgXZ7R0= Received: by 10.38.207.26 with SMTP id e26mr17241rng; Thu, 17 Feb 2005 07:27:22 -0800 (PST) Received: by 10.38.151.18 with HTTP; Thu, 17 Feb 2005 07:27:22 -0800 (PST) Message-ID: <3f1451f50502170727c6f24b9@mail.gmail.com> Date: Thu, 17 Feb 2005 10:27:22 -0500 From: Joe Gregorio To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] In-Reply-To: <4214A21E.5070804@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4211E442.40209@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> X-Spam-Score: 0.024 () RCVD_BY_IP X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Thu, 17 Feb 2005 09:48:41 -0800 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Joe Gregorio List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 15:27:29 -0000 On Thu, 17 Feb 2005 14:54:38 +0100, Julian Reschke wrote: > > Roy T. Fielding wrote: > > It doesn't because it never needed it. > > OK, let's step back and look at the situation that caused me to make > this proposal. > > Two separate communities (CalDAV/GroupDav and Atompub) encountered the > same issue: what's the best way to create a new resource on an HTTP > server when I can't use PUT as the URI space may be entirely > server-controlled? > > 1) CalDav's approach is: use PUT to an arbitrary member URI of the > container; then let the server automagically move it somewhere else, and > report that in the Location response header > (). > > 2) Atom's approach is to use service URIs to which the client can POST, > and to discover these service URIs by parting entity (feed) bodies. To be clear, Atom uses POST + media-type ==> 201 + location exactly as Roy outlined. As you point out, there is an issue with the discovery of the URI to POST to, but I'll get back to that below. > Somehow I have the (perhaps naive) wish that identical requirements > should lead to common protocol constructs. > > 1) Seems to break PUT semantics; > > 2) Is specific to Atom and not applicable to other protocols. None of what Atom does is specific to Atom, unless you count the media-type of "application/atom+xml". The real source of the problem/disconnect here seems to be not over the semantics of PUT or POST, but goes back a level further into the differences betweeen Atom and WebDAV and how they use URIs, which in turn may foster different solutions to the problem of resource creation. To make this clear, let's define two terms: URI Construction: An algorithm for pasting together some information into URI path and query parameters to form a URI. Two examples: 1. WebDAV's use of PUT. To create a new resource append to the path your are currently using and PUT a representation to that URI. 2. Del.icio.us API (http://del.icio.us/doc/api) Ignoring for now the non-idenpotent uses of GET, the API is just a recipe for how to construct URIs. Hypertext Navigation: Following opaque URIs in a hypertext document. Example: The element in HTML. Now we can categorize: Atom: All URIs are opaque and it uses Hypertext Navigation to find URIs. WebDAV: In many instances uses URI Construction. HTML: Uses a blend of both. For example elements are pure Hypertext Navigation, while HTML Forms that use GET use a combination, creating a URI from data in the Hypertext to construct a URI. As a side note, what does seem to be missing is a generic mechanism for URI construction using data culled from hypertext that can be used for web services. That is, while HTML can construct Form GET requests using query parameters there is no analogue for constructing path and query components of a URI from XML documents. -joe -- Joe Gregorio http://bitworking.org X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HEjfaZ026724 for ; Thu, 17 Feb 2005 06:45:41 -0800 Received: (qmail invoked by alias); 17 Feb 2005 14:45:35 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp006) with SMTP; 17 Feb 2005 15:45:35 +0100 X-Authenticated: #1915285 Message-ID: <4214AE0E.4080202@gmx.de> Date: Thu, 17 Feb 2005 15:45:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jamie Lokier Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> <20050217143606.GA14754@mail.shareable.org> In-Reply-To: <20050217143606.GA14754@mail.shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 14:45:44 -0000 Jamie Lokier wrote: > Julian Reschke wrote: > >>2) Atom's approach is to use service URIs to which the client can POST, >>and to discover these service URIs by parting entity (feed) bodies. > > ... > >>2) Is specific to Atom and not applicable to other protocols. > > > ADDMEMBER is no different from POST in this respect: > > You still have to "discover the service URI" to use with ADDMEMBER. No, it would be the container resource itself. For CalDav, the calendar collection; for Atompub, the feed resource itself. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1HEaKaa026053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2005 06:36:22 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1HEaB81014900; Thu, 17 Feb 2005 14:36:11 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1HEa6xB014890; Thu, 17 Feb 2005 14:36:06 GMT Date: Thu, 17 Feb 2005 14:36:06 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050217143606.GA14754@mail.shareable.org> References: <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> <4214A21E.5070804@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4214A21E.5070804@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , "Roy T. Fielding" , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 14:36:23 -0000 Julian Reschke wrote: > 2) Atom's approach is to use service URIs to which the client can POST, > and to discover these service URIs by parting entity (feed) bodies. ... > 2) Is specific to Atom and not applicable to other protocols. ADDMEMBER is no different from POST in this respect: You still have to "discover the service URI" to use with ADDMEMBER. -- JAmie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1HDsraZ023119 for ; Thu, 17 Feb 2005 05:54:54 -0800 Received: (qmail invoked by alias); 17 Feb 2005 13:54:47 -0000 Received: from p508243CD.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.67.205) by mail.gmx.net (mp001) with SMTP; 17 Feb 2005 14:54:47 +0100 X-Authenticated: #1915285 Message-ID: <4214A21E.5070804@gmx.de> Date: Thu, 17 Feb 2005 14:54:38 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> In-Reply-To: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Mark Baker , WebDAV , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 13:54:58 -0000 Roy T. Fielding wrote: > POST is always an attempt to store state. It is the response that > tells you whether the state has been stored. No POST can be > interpreted by intermediaries, just as no "ADDMEMBER" can either. > The system gains nothing from adding a new method. It might have > gained something by not allowing HTML forms to use POST for safe > actions, but that debate ended years ago. Creating new unsafe > actions that do the same as what POST has already been defined > to do is absurd. Well, ADDMEMBER does not do the same thing. It's specced to do *one* very specific thing, while POST basically allows the server to do anything it likes. >> Had HTTP a means for extending a method to declare this additional >> expectation (as described in the draft's A.3 using RFC 2774), I agree >> that POST + extension would be appropriate. > > > It doesn't because it never needed it. OK, let's step back and look at the situation that caused me to make this proposal. Two separate communities (CalDAV/GroupDav and Atompub) encountered the same issue: what's the best way to create a new resource on an HTTP server when I can't use PUT as the URI space may be entirely server-controlled? 1) CalDav's approach is: use PUT to an arbitrary member URI of the container; then let the server automagically move it somewhere else, and report that in the Location response header (). 2) Atom's approach is to use service URIs to which the client can POST, and to discover these service URIs by parting entity (feed) bodies. Somehow I have the (perhaps naive) wish that identical requirements should lead to common protocol constructs. 1) Seems to break PUT semantics; 2) Is specific to Atom and not applicable to other protocols. > ... > The media type is not limited in HTTP and it is not equivalent > to data format. The media type tells the recipient how to process > the message given the method semantics. That is why sending the > same data as "text/html" is functionally different from sending it > as "text/plain" -- the two messages have different semantics. > > That will hold for anything compliant with HTTP/1.1. So what would be your recommendation to the authors of CalDav and the Atom Publishing Protocol? What's the best way to add a new member to a container (storing the entity just like PUT, but letting the server decide on the URI)? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1H1jkaa027410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Feb 2005 17:45:46 -0800 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D1ajg-0008SW-QS; Wed, 16 Feb 2005 17:45:44 -0800 In-Reply-To: <20050216125342.GA4504@markbaker.ca> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <683a9392671e29b5f4fdfe7fd5089a25@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Wed, 16 Feb 2005 17:45:46 -0800 To: Mark Baker X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 01:45:46 -0000 On Feb 16, 2005, at 4:53 AM, Mark Baker wrote: > On Tue, Feb 15, 2005 at 03:02:46PM -0800, Roy T. Fielding wrote: >> >> This feature of HTTP is already defined as >> >> POST + media-type ==> 201 + location > > I was thinking the same thing Roy, but a new method would have the > advantage of improved visibility; an intermediary observing a POST/201 > interaction wouldn't see anything in the POST request which licensed it > to interpret that request as an attempt to store state, whereas a new > method would provide exactly that license. POST is always an attempt to store state. It is the response that tells you whether the state has been stored. No POST can be interpreted by intermediaries, just as no "ADDMEMBER" can either. The system gains nothing from adding a new method. It might have gained something by not allowing HTML forms to use POST for safe actions, but that debate ended years ago. Creating new unsafe actions that do the same as what POST has already been defined to do is absurd. > Had HTTP a means for extending a method to declare this additional > expectation (as described in the draft's A.3 using RFC 2774), I agree > that POST + extension would be appropriate. It doesn't because it never needed it. >> The media type is more than >> sufficient to distinguish this action from any other type of >> misdirected POST, > > How so? Because the target URI knows what type of collection it is and how to process POST requests. > AFAICT, the media type could be anything. Did I miss something > in the I-D? The I-D is irrelevant -- the feature already exists in RFC 2616 and all predecessors. > But even if there was such a limitation, that seems a bit > kludgy to me; could such an assumption be expected to hold for even the > foreseeable future? I wouldn't have thought so. The media type is not limited in HTTP and it is not equivalent to data format. The media type tells the recipient how to process the message given the method semantics. That is why sending the same data as "text/html" is functionally different from sending it as "text/plain" -- the two messages have different semantics. That will hold for anything compliant with HTTP/1.1. ....Roy X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1GErhaa025333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Feb 2005 06:53:48 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1GErS81026892; Wed, 16 Feb 2005 14:53:28 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1GErQ1Q026890; Wed, 16 Feb 2005 14:53:26 GMT Date: Wed, 16 Feb 2005 14:53:25 +0000 From: Jamie Lokier To: Mark Baker Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050216145325.GA25127@mail.shareable.org> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> <20050216125342.GA4504@markbaker.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050216125342.GA4504@markbaker.ca> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: "Roy T. Fielding" , HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 14:53:58 -0000 Mark Baker wrote: > > This feature of HTTP is already defined as > > > > POST + media-type ==> 201 + location > > I was thinking the same thing Roy, but a new method would have the > advantage of improved visibility; an intermediary observing a POST/201 > interaction wouldn't see anything in the POST request which licensed it > to interpret that request as an attempt to store state, whereas a new > method would provide exactly that license. What kind of POST does -not- involve an attempt to store state? RFC 2616: POST is designed to allow a uniform method to cover the following functions: - Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation. I'm trying to imagine what you think an intermediary (or generic client) would do with the proposed method differently from what it would do with POST. They are both an attempt to modify state on the server, and both potentially result in a created resource with a new URI. I don't see how the intermediary is supposed to treat them differently, so can you give an example? -- Jamie X-Envelope-From: distobj@acm.org X-Envelope-To: Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1GCsRaZ003251 for ; Wed, 16 Feb 2005 04:54:28 -0800 Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1D1OgY-0001wb-00; Wed, 16 Feb 2005 07:53:42 -0500 Date: Wed, 16 Feb 2005 07:53:42 -0500 From: Mark Baker To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050216125342.GA4504@markbaker.ca> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Wed, 16 Feb 2005 09:03:06 -0800 Cc: HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 12:54:29 -0000 On Tue, Feb 15, 2005 at 03:02:46PM -0800, Roy T. Fielding wrote: > > This feature of HTTP is already defined as > > POST + media-type ==> 201 + location I was thinking the same thing Roy, but a new method would have the advantage of improved visibility; an intermediary observing a POST/201 interaction wouldn't see anything in the POST request which licensed it to interpret that request as an attempt to store state, whereas a new method would provide exactly that license. Had HTTP a means for extending a method to declare this additional expectation (as described in the draft's A.3 using RFC 2774), I agree that POST + extension would be appropriate. > The media type is more than > sufficient to distinguish this action from any other type of > misdirected POST, How so? AFAICT, the media type could be anything. Did I miss something in the I-D? But even if there was such a limitation, that seems a bit kludgy to me; could such an assumption be expected to hold for even the foreseeable future? I wouldn't have thought so. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1FNUxaa003711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2005 15:31:00 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1FNUu81017122; Tue, 15 Feb 2005 23:30:56 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1FNUuFI017120; Tue, 15 Feb 2005 23:30:56 GMT Date: Tue, 15 Feb 2005 23:30:56 +0000 From: Jamie Lokier To: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050215233056.GA16618@mail.shareable.org> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: HTTP Working Group , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 23:31:01 -0000 Roy T. Fielding wrote: > > This feature of HTTP is already defined as > > POST + media-type ==> 201 + location > > There is no need for any new methods, header fields, or any of > the other assorted proposals to add more crap to HTTP. The client > knows what it is doing and can tell from the server's response > whether or not it succeeded. The media type is more than > sufficient to distinguish this action from any other type of > misdirected POST, and thus there is no need to check ahead of > time whether or not the feature is supported. I agree 100%. Especially about the media type. As if anyone needs a bit more clarity, RFC2616 says, under POST: If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30). > This has been the original definition of POST going back to 1992. > It is based on NNTP's post command and has the property of adding > resources to a collection under a name chosen by the receiving > server. Absolutely. Thank you for stating it clearly. -- Jamie X-Envelope-From: fielding@gbiv.com X-Envelope-To: Received: from scorpio.lunarpages.com (scorpio.lunarpages.com [64.235.234.122]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1FN2kaa032468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2005 15:02:47 -0800 Received: from wsip-24-248-98-242.oc.oc.cox.net ([24.248.98.242] helo=[10.2.8.58]) by scorpio.lunarpages.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.44) id 1D1BiQ-00056x-1B; Tue, 15 Feb 2005 15:02:46 -0800 In-Reply-To: References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6b6b83dd7bd439f4c7e87ce5df886f53@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Tue, 15 Feb 2005 15:02:46 -0800 To: HTTP Working Group X-Mailer: Apple Mail (2.619.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Tue, 15 Feb 2005 15:32:42 -0800 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 23:02:50 -0000 This feature of HTTP is already defined as POST + media-type ==> 201 + location There is no need for any new methods, header fields, or any of the other assorted proposals to add more crap to HTTP. The client knows what it is doing and can tell from the server's response whether or not it succeeded. The media type is more than sufficient to distinguish this action from any other type of misdirected POST, and thus there is no need to check ahead of time whether or not the feature is supported. This has been the original definition of POST going back to 1992. It is based on NNTP's post command and has the property of adding resources to a collection under a name chosen by the receiving server. Cheers, Roy T. Fielding Chief Scientist, Day Software X-Envelope-From: helge.hess@opengroupware.org X-Envelope-To: Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1FLhVaZ025002 for ; Tue, 15 Feb 2005 13:43:31 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 524FA2DA873; Tue, 15 Feb 2005 22:42:48 +0100 (CET) Received: from [192.168.1.233] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 5FAD92DA86B; Tue, 15 Feb 2005 22:42:47 +0100 (CET) In-Reply-To: <4212366A.5010003@gmx.de> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: From: Helge Hess Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Date: Tue, 15 Feb 2005 22:43:15 +0100 To: HTTP Working Group X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j1FLhVaZ025002 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 21:43:33 -0000 On 15. Feb 2005, at 18:50 Uhr, Julian Reschke wrote: > OK, I'll have to update the draft with a problem description :-). > > HTTP 2616 says in Section 9.6 > (): > > "The PUT method requests that the enclosed entity be stored under the > supplied Request-URI. If the Request-URI refers to an already existing > resource, the enclosed entity SHOULD be considered as a modified > version of the one residing on the origin server. If the Request-URI > does not point to an existing resource, and that URI is capable of > being defined as a new resource by the requesting user agent, the > origin server can create the resource with that URI." > > That is, a server that stores the entity under a different URI than > the one provided by the client isn't doing what the client asked for. > > Therefore I propose that the client should explicitly state what it > wants. One approach is a new method, other approaches would be to > extend the PUT *request*. I can't resist but to post it once again, sorry about that ;-): http://greenbytes.de/tech/webdav/rfc2616.html#status.201 ---snip--- 10.2.2 201 Created The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. ... ---snap--- I still have the opinion that PUT+201+location+if-none-match as a way to create new items is in the core HTTP spec and that we don't need a new method nor a PUT extension for that. IMHO the only thing which is really missing is a review on which WebDAV clients (few other support PUT?) have issues with a location header (or not). best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: scarr@progbits.com X-Envelope-To: Received: from exchange01.corp.dccusa.com (dccmailam.dccusa.com [12.107.242.101]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1FLONaZ023165 for ; Tue, 15 Feb 2005 13:24:23 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Feb 2005 15:25:17 -0600 Message-ID: <4212689A.5060508@progbits.com> Date: Tue, 15 Feb 2005 15:24:42 -0600 From: Scott Carr User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> In-Reply-To: <42122891.3010801@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2005 21:25:17.0608 (UTC) FILETIME=[D8666280:01C513A4] X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 21:24:26 -0000 Julian Reschke wrote: > Yes, but protocols should not mandate a behaviour that directly > contradicts it's definition in the base protocol -- *even* if it > applies only to special clients. > Julian, I definately understand your concern, I brought up event naming myself not too long ago on the list. One of the problems that you run into if we don't possibly change the put behavior is there are too many round trips and it bogs down a server to the point it can't do much else. Imagine if a meeting request comes in for 150 people. Each of those people would then turn around and add a new event. If each one of those has to do two round trips to get an event entered, something that will happen pretty regularly anyway, it could potentially bring the server to a crawl. Then you add that the server may be processing emails, and other items for the company, the add process ends up having to be pretty quick on the implementation side. The feature doesn't really modify the spec totally, from what I remember I believe their was a header being talked about that could tell the server if it exists to change the resource name and pass back a location header. This feature could be used in other areas as well, like a Contact storage, a Notes storage. The mechanism could be beneficial, in each of these areas. -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org X-Envelope-From: jamie@shareable.org X-Envelope-To: 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 j1FIWBaa000841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2005 10:32:13 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id j1FIVr81012574; Tue, 15 Feb 2005 18:31:53 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id j1FIVruQ012572; Tue, 15 Feb 2005 18:31:53 GMT Date: Tue, 15 Feb 2005 18:31:53 +0000 From: Jamie Lokier To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <20050215183153.GA12402@mail.shareable.org> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> <4212366A.5010003@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4212366A.5010003@gmx.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Tue, 15 Feb 2005 10:55:21 -0800 Cc: HTTP Working Group , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 18:32:15 -0000 Julian Reschke wrote: > "The PUT method requests that the enclosed entity be stored under the > supplied Request-URI. If the Request-URI refers to an already existing > resource, the enclosed entity SHOULD be considered as a modified version > of the one residing on the origin server. If the Request-URI does not > point to an existing resource, and that URI is capable of being defined > as a new resource by the requesting user agent, the origin server can > create the resource with that URI." > > That is, a server that stores the entity under a different URI than the > one provided by the client isn't doing what the client asked for. > > Therefore I propose that the client should explicitly state what it > wants. One approach is a new method, other approaches would be to extend > the PUT *request*. These clients creating entities under different URIs -- what URI do they use in the request? They must use a URI which identifies what the server should do with the request, rather than identifying the URI of the new entity. (For example, a real implementation might use the URI identifying a particular mail folder or calendar in the request, and the request is to create a new message "inside" the identified folder or calendar, with a server-selected URI). When the request URI identifies an object which has internal logic and processes the request body -- isn't this quite well suited to POST? And, to get the URI of the created entity -- isn't this quite well suited to a 303 response from POST? (For example, POST to a mail folder or calender URI could reasonably create a new message "inside" the identified folder or calendar, if the request entity has an appropriate MIME type). -- Jamie X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1FHogaZ028700 for ; Tue, 15 Feb 2005 09:50:42 -0800 Received: (qmail invoked by alias); 15 Feb 2005 17:50:36 -0000 Received: from p50824ABC.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.74.188) by mail.gmx.net (mp010) with SMTP; 15 Feb 2005 18:50:36 +0100 X-Authenticated: #1915285 Message-ID: <4212366A.5010003@gmx.de> Date: Tue, 15 Feb 2005 18:50:34 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: HTTP Working Group , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 17:50:44 -0000 Cyrus Daboo wrote: > Hi Julian, > > --On February 15, 2005 5:51:29 PM +0100 Julian Reschke > wrote: > >> Yes, but protocols should not mandate a behaviour that directly >> contradicts it's definition in the base protocol -- *even* if it applies >> only to special clients. >> > > Well, I don't see this as 'contradicting' the base protocol, rather its > 'extending' it to clarify behaviour that some servers (perfectly > legitimately) may do. OK, I'll have to update the draft with a problem description :-). HTTP 2616 says in Section 9.6 (): "The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI." That is, a server that stores the entity under a different URI than the one provided by the client isn't doing what the client asked for. Therefore I propose that the client should explicitly state what it wants. One approach is a new method, other approaches would be to extend the PUT *request*. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1FHcaaa027861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2005 09:38:39 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1FHTP6g021117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Feb 2005 12:29:25 -0500 Date: Tue, 15 Feb 2005 12:38:31 -0500 From: Cyrus Daboo To: Julian Reschke Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: In-Reply-To: <42122891.3010801@gmx.de> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> <42122891.3010801@gmx.de> X-Mailer: Mulberry/4.0.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: HTTP Working Group , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 17:38:43 -0000 Hi Julian, --On February 15, 2005 5:51:29 PM +0100 Julian Reschke wrote: > Yes, but protocols should not mandate a behaviour that directly > contradicts it's definition in the base protocol -- *even* if it applies > only to special clients. > Well, I don't see this as 'contradicting' the base protocol, rather its 'extending' it to clarify behaviour that some servers (perfectly legitimately) may do. -- Cyrus Daboo X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1FGpdaZ025028 for ; Tue, 15 Feb 2005 08:51:39 -0800 Received: (qmail invoked by alias); 15 Feb 2005 16:51:33 -0000 Received: from p50824ABC.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.74.188) by mail.gmx.net (mp021) with SMTP; 15 Feb 2005 17:51:33 +0100 X-Authenticated: #1915285 Message-ID: <42122891.3010801@gmx.de> Date: Tue, 15 Feb 2005 17:51:29 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> In-Reply-To: <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: HTTP Working Group , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 16:51:41 -0000 Cyrus Daboo wrote: >>> How is a client supposed to know to use ADDMEMBER as opposed to PUT? >>> Does it have to check OPTIONS each time before it creates a resource in >>> a new part of the URI hierarchy? >> >> >> If it does have a name it can try the PUT which will fail; we could >> define a simple way to find out that it's supposed to use ADDMEMBER >> instead (such as a specific precondition name for DAV:error). > > > But the PUT does not fail. It succeeds, however the server immediately > 'moves' the resource to a new location and the client does not know > about that. Alternatively the server would return a new '4xx Try > ADDMEMBER' response code - but I would argue my proposal for a '2xx > Created and Moved' is a better solution as it only needs one roundtrip. The whole point of the proposal is to offer an alternative to what CalDav proposes, because (IMHO) that violates PUT semantics. >> If it doesn't have a name it can try ADDMEMBER right away (which will >> fail if the server can't do it). > > > There are actually two problems here: > > 1) Servers that cannot accept arbitrary client-generated URIs on new > resources and need to 'rename' those to something that is internally > consistent with its own policies. > > 2) Clients that 'dont care' about the name of the resource being created > - they just want it to be unique and leave it up to the server to > generate the name. > > I thought we were only trying to solve (1), but your ADDMEMBER proposal > also solves (2). However, (2) is also relevant for MKxxx, MOVE and COPY > and we don't have those solved. It doesn't attempt to solve those for anything other than plain resources, and not for namespace operations. That's why it's so simple. >>> Is there any reason why we can't simply define a new status code for a >>> PUT (or MKCOL) that results in the resource being renamed by the server? >>> e.g.: >>> >>> PUT /calendar/evt1.ics HTTP/1.1 >>> Host: localhost >>> ... >>> >>> HTTP/1.1 2xx Created and Moved >>> Location: /calendar/xyz123.ics >> >> >> As far as I can tell, a server doing that wouldn't implement the >> specified PUT semantics anymore. > > > One could argue that the types of server we are talking about don't > implement PUT semantics anyway, by virtue of the fact that they move the > resource as soon as it is created without telling the client. So '2xx > Created and Moved' is no worse than the current state for existing > clients - but it is better for clients that are 'aware' of this behaviour. Yes, but protocols should not mandate a behaviour that directly contradicts it's definition in the base protocol -- *even* if it applies only to special clients. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1FGPEaa023316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2005 08:25:15 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1FGG46g019098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Feb 2005 11:16:05 -0500 Date: Tue, 15 Feb 2005 11:25:09 -0500 From: Cyrus Daboo To: Julian Reschke , HTTP Working Group Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <62F35864CD746B25C06E1A19@ninevah.cyrusoft.com> In-Reply-To: <42121E4A.3080007@gmx.de> References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> <42121E4A.3080007@gmx.de> X-Mailer: Mulberry/4.0.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 16:25:18 -0000 Hi Julian, --On February 15, 2005 5:07:38 PM +0100 Julian Reschke wrote: > Cyrus Daboo wrote: > > (following up on ietf-http-wg@w3.org) > >> Do we anticipate that MKCOL will also have the same problem as PUT? i.e. >> do we have to have an 'ADDCOLLECTION' method to take care of that case? > > That's a good question that I thought about as well (but forgot to add a > reminder for). In this version, I tried to stick with > terminology/features of base HTTP (where MKCOL doesn't exist). I think this server behaviour will impact WebDAV too (at least in the CalDAV case). >> How is a client supposed to know to use ADDMEMBER as opposed to PUT? >> Does it have to check OPTIONS each time before it creates a resource in >> a new part of the URI hierarchy? > > If it does have a name it can try the PUT which will fail; we could > define a simple way to find out that it's supposed to use ADDMEMBER > instead (such as a specific precondition name for DAV:error). But the PUT does not fail. It succeeds, however the server immediately 'moves' the resource to a new location and the client does not know about that. Alternatively the server would return a new '4xx Try ADDMEMBER' response code - but I would argue my proposal for a '2xx Created and Moved' is a better solution as it only needs one roundtrip. > If it doesn't have a name it can try ADDMEMBER right away (which will > fail if the server can't do it). There are actually two problems here: 1) Servers that cannot accept arbitrary client-generated URIs on new resources and need to 'rename' those to something that is internally consistent with its own policies. 2) Clients that 'dont care' about the name of the resource being created - they just want it to be unique and leave it up to the server to generate the name. I thought we were only trying to solve (1), but your ADDMEMBER proposal also solves (2). However, (2) is also relevant for MKxxx, MOVE and COPY and we don't have those solved. >> Is there any reason why we can't simply define a new status code for a >> PUT (or MKCOL) that results in the resource being renamed by the server? >> e.g.: >> >> PUT /calendar/evt1.ics HTTP/1.1 >> Host: localhost >> ... >> >> HTTP/1.1 2xx Created and Moved >> Location: /calendar/xyz123.ics > > As far as I can tell, a server doing that wouldn't implement the > specified PUT semantics anymore. One could argue that the types of server we are talking about don't implement PUT semantics anyway, by virtue of the fact that they move the resource as soon as it is created without telling the client. So '2xx Created and Moved' is no worse than the current state for existing clients - but it is better for clients that are 'aware' of this behaviour. >> Yes, this would probably break existing http clients doing a PUT, but >> those clients are going to have problems anyway since the server will >> rename the resource from under them anyway. What it does do is provide a >> clear indication for clients that can understand this behaviour. What is >> more this response code can be used on any method that creates resources >> without the need to have separate new methods for this. e.g. there are >> now a whole host of MKxxxx methods that may need the same treatment as >> PUT. The same probably applies to MOVE and COPY too. > > I think it needs to be discussed whether you need a > "server-defines-the-URL" variant for all these methods. If that is indeed > the case, I'd propose to use a optional extension (RFC2774) through which > a client could explicitly state that that behaviour is acceptable. I think it would be reasonable for a client request to contain a header that indicates it knows how to handle '2xx Created and Moved' which will then allow the server to generate that response code if it needs to. -- Cyrus Daboo X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1FG7kaZ022128 for ; Tue, 15 Feb 2005 08:07:47 -0800 Received: (qmail invoked by alias); 15 Feb 2005 16:07:40 -0000 Received: from p50824ABC.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.74.188) by mail.gmx.net (mp009) with SMTP; 15 Feb 2005 17:07:40 +0100 X-Authenticated: #1915285 Message-ID: <42121E4A.3080007@gmx.de> Date: Tue, 15 Feb 2005 17:07:38 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: HTTP Working Group Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] References: <4211E442.40209@gmx.de> <27514C16D36854827D284790@ninevah.cyrusoft.com> In-Reply-To: <27514C16D36854827D284790@ninevah.cyrusoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 16:07:49 -0000 Cyrus Daboo wrote: (following up on ietf-http-wg@w3.org) > Do we anticipate that MKCOL will also have the same problem as PUT? i.e. > do we have to have an 'ADDCOLLECTION' method to take care of that case? That's a good question that I thought about as well (but forgot to add a reminder for). In this version, I tried to stick with terminology/features of base HTTP (where MKCOL doesn't exist). > How is a client supposed to know to use ADDMEMBER as opposed to PUT? > Does it have to check OPTIONS each time before it creates a resource in > a new part of the URI hierarchy? If it does have a name it can try the PUT which will fail; we could define a simple way to find out that it's supposed to use ADDMEMBER instead (such as a specific precondition name for DAV:error). If it doesn't have a name it can try ADDMEMBER right away (which will fail if the server can't do it). > Is there any reason why we can't simply define a new status code for a > PUT (or MKCOL) that results in the resource being renamed by the server? > e.g.: > > PUT /calendar/evt1.ics HTTP/1.1 > Host: localhost > ... > > HTTP/1.1 2xx Created and Moved > Location: /calendar/xyz123.ics As far as I can tell, a server doing that wouldn't implement the specified PUT semantics anymore. > Yes, this would probably break existing http clients doing a PUT, but > those clients are going to have problems anyway since the server will > rename the resource from under them anyway. What it does do is provide a > clear indication for clients that can understand this behaviour. What is > more this response code can be used on any method that creates resources > without the need to have separate new methods for this. e.g. there are > now a whole host of MKxxxx methods that may need the same treatment as > PUT. The same probably applies to MOVE and COPY too. I think it needs to be discussed whether you need a "server-defines-the-URL" variant for all these methods. If that is indeed the case, I'd propose to use a optional extension (RFC2774) through which a client could explicitly state that that behaviour is acceptable. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: daboo@isamet.com X-Envelope-To: Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1FFokaa020838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2005 07:50:52 -0800 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j1FFfE6g018213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Feb 2005 10:41:15 -0500 Date: Tue, 15 Feb 2005 10:50:20 -0500 From: Cyrus Daboo To: Julian Reschke , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00] Message-ID: <27514C16D36854827D284790@ninevah.cyrusoft.com> In-Reply-To: <4211E442.40209@gmx.de> References: <4211E442.40209@gmx.de> X-Mailer: Mulberry/4.0.0a5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 15:50:54 -0000 Hi Julian, --On February 15, 2005 1:00:02 PM +0100 Julian Reschke wrote: > recently different communities (caldav/groupdav, atompup (protocol > part)) have been discussing how to use HTTP to author new resources when > the URL namespace is completely server-controlled, thus PUT just doesn't > fit well. > > A simple approach would be to define a new HTTP method which is *almost* > like PUT, except that the server chooses the URL to create (and returns > it in the Location header). > > I've submitted a first draft as "draft-reschke-http-addmember-00". Note > that it also contains an appendix covering possible alternative > approaches. > > Feedback appreciated, > Do we anticipate that MKCOL will also have the same problem as PUT? i.e. do we have to have an 'ADDCOLLECTION' method to take care of that case? How is a client supposed to know to use ADDMEMBER as opposed to PUT? Does it have to check OPTIONS each time before it creates a resource in a new part of the URI hierarchy? Is there any reason why we can't simply define a new status code for a PUT (or MKCOL) that results in the resource being renamed by the server? e.g.: PUT /calendar/evt1.ics HTTP/1.1 Host: localhost ... HTTP/1.1 2xx Created and Moved Location: /calendar/xyz123.ics Yes, this would probably break existing http clients doing a PUT, but those clients are going to have problems anyway since the server will rename the resource from under them anyway. What it does do is provide a clear indication for clients that can understand this behaviour. What is more this response code can be used on any method that creates resources without the need to have separate new methods for this. e.g. there are now a whole host of MKxxxx methods that may need the same treatment as PUT. The same probably applies to MOVE and COPY too. -- Cyrus Daboo X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1FCAdaZ008530 for ; Tue, 15 Feb 2005 04:10:40 -0800 Received: (qmail invoked by alias); 15 Feb 2005 12:10:33 -0000 Received: from p50824ABC.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.74.188) by mail.gmx.net (mp021) with SMTP; 15 Feb 2005 13:10:33 +0100 X-Authenticated: #1915285 Message-ID: <4211E6B7.3000204@gmx.de> Date: Tue, 15 Feb 2005 13:10:31 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> <420C3FDD.3080308@oracle.com> In-Reply-To: <420C3FDD.3080308@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 12:10:44 -0000 Bernard Desruisseaux wrote: > Julian, > > Thanks for your comments! The -05 draft addresses most of > the issues you have reported. See my comments below. > > I'll keep track of the issues that are not yet addressed. Thanks. In general, the new draft seems to be a big improvement. I currently do not have the time fot a in-depth review, but I noticed that you have started to use OPTIONS request bodies similar to RFC3253. However, that approach is sort-of deprecated (check out ), so you may want to consider moving to live properties instead. Some more comments inline... > > The example given (resource created at a different URI) seems to violate > > HTTP semantics: if PUT doesn't actually create a resource at the > > Request-URI, a status code of 201 (actually any 2xx code) seems to be > > wrong. > > This issue is not addressed yet. See draft-reschke-http-addmember-00 () for an alternate proposal... > > It's a bit unclear why the spec needs to extend multistatus, that is, > > why the requested ical information can't be returned in the form of > > promoted properties (I think this would greatly simplify the spec). > > In Section 12.11 of RFC 2518 it says: > > The prop XML element is a generic container for properties > defined on resources. All elements inside a prop XML element > MUST define properties related to the resource. No other > elements may be used inside of a prop element. > > Given that the value of calendar-query-result (renamed to > calendar-data in draft -05) depends on the request body of > a REPORT, could we really claim that it "defines properties > related to the resource"? Yes, that doesn't seem to be a problem. > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: julian.reschke@gmx.de X-Envelope-To: Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1FC0AaZ007440 for ; Tue, 15 Feb 2005 04:00:11 -0800 Received: (qmail invoked by alias); 15 Feb 2005 12:00:04 -0000 Received: from p50824ABC.dip0.t-ipconnect.de (EHLO [192.168.1.87]) (80.130.74.188) by mail.gmx.net (mp015) with SMTP; 15 Feb 2005 13:00:04 +0100 X-Authenticated: #1915285 Message-ID: <4211E442.40209@gmx.de> Date: Tue, 15 Feb 2005 13:00:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] [Fwd: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 12:00:13 -0000 (fyi) -------- Original Message -------- > ... Hi, recently different communities (caldav/groupdav, atompup (protocol part)) have been discussing how to use HTTP to author new resources when the URL namespace is completely server-controlled, thus PUT just doesn't fit well. A simple approach would be to define a new HTTP method which is *almost* like PUT, except that the server chooses the URL to create (and returns it in the Location header). I've submitted a first draft as "draft-reschke-http-addmember-00". Note that it also contains an appendix covering possible alternative approaches. Feedback appreciated, Julian HTML version: Latest edits will be at: bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet03.oracle.com (rgminet03.oracle.com [148.87.122.32]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1F2E8aa030348 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 14 Feb 2005 18:14:09 -0800 Received: from rgminet03.oracle.com (localhost [127.0.0.1]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1F2DuZk019208; Mon, 14 Feb 2005 21:13:56 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1F29U6C015726; Mon, 14 Feb 2005 21:10:29 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1F29TBs012655; Mon, 14 Feb 2005 19:09:30 -0700 Received: from [192.168.1.200] (dhcp-amer-rmdc-csvpn-gw6-141-144-113-47.vpn.oracle.com [141.144.113.47]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1F29QvB012632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Feb 2005 19:09:26 -0700 Message-ID: <421159D2.4090309@oracle.com> Date: Mon, 14 Feb 2005 21:09:22 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: "Kervin L. Pierre" Subject: Re: separate scheduling? - Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> <420C3FDD.3080308@oracle.com> <42113F9C.5090904@adevsoft.com> In-Reply-To: <42113F9C.5090904@adevsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 02:14:09 -0000 Kervin, There are no specific issues really. Some people were concerned that the publication of CalDAV would be delayed because the specification was trying to address both calendar access and scheduling. Given that some people are currently only interested in the "calendar-access" feature of CalDAV, and given that Lisa, Cyrus and myself believe we are going to be done with "calendar-access" soon, we have decided to split the document and get a first CalDAV draft published. Given that support for "calendar-schedule" was already optional, I don't think this is a big change. The authors are still committed to get the "calendar-schedule" feature published. The goals and scope of CalDAV have not changed. The authors have simply adopted a phased approach to get CalDAV in the hands of end users as soon as possible. I hope that address your concerns. Cheers, Bernard Kervin L. Pierre wrote: > Bernard Desruisseaux wrote: > >> >> The scheduling part of CalDAV has been moved into a >> separate draft. Those issues will be addressed later. >> >> > > Anyone care to comment on that decision a little? > > I am not questioning it, but it seems like a very > big change. > > What were the specific issues which led to this > decision? Understanding those may help us better > understand the apparently revised goals and scope > of the new protocol. > > Thanks, > Kervin > > X-Envelope-From: kervin@adevsoft.com X-Envelope-To: Received: from svr59.edns1.com (svr59.edns1.com [67.15.20.32]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1F0Hbaa023985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Feb 2005 16:17:38 -0800 Received: from host9-60.wrls.fit.edu ([163.118.9.60]) by svr59.edns1.com with esmtpa (Exim 4.43) id 1D0qPD-0004pc-Tc; Mon, 14 Feb 2005 16:17:32 -0800 Message-ID: <42113F9C.5090904@adevsoft.com> Date: Mon, 14 Feb 2005 19:17:32 -0500 From: "Kervin L. Pierre" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050212 MIME-Version: 1.0 To: Bernard Desruisseaux Subject: separate scheduling? - Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> <420C3FDD.3080308@oracle.com> In-Reply-To: <420C3FDD.3080308@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr59.edns1.com X-AntiAbuse: Original Domain - osafoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - adevsoft.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 00:17:40 -0000 Bernard Desruisseaux wrote: > > The scheduling part of CalDAV has been moved into a > separate draft. Those issues will be addressed later. > > Anyone care to comment on that decision a little? I am not questioning it, but it seems like a very big change. What were the specific issues which led to this decision? Understanding those may help us better understand the apparently revised goals and scope of the new protocol. Thanks, Kervin X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1EMbiaa010642 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 14 Feb 2005 14:37:44 -0800 Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j1EMWGXL018574; Mon, 14 Feb 2005 14:37:34 -0800 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j1B5HPiM002244; Thu, 10 Feb 2005 21:18:15 -0800 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1B5HPOW009822; Thu, 10 Feb 2005 22:17:25 -0700 Received: from [192.168.1.200] (dhcp-amer-csvpn-gw1-141-144-64-102.vpn.oracle.com [141.144.64.102]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1B5HKGa009799 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Feb 2005 22:17:22 -0700 Message-ID: <420C3FDD.3080308@oracle.com> Date: Fri, 11 Feb 2005 00:17:17 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: Julian Reschke Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-04 References: <41D8433E.2000305@gmx.de> In-Reply-To: <41D8433E.2000305@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 22:37:47 -0000 Julian, Thanks for your comments! The -05 draft addresses most of the issues you have reported. See my comments below. I'll keep track of the issues that are not yet addressed. Cheers, Bernard Julian Reschke wrote: > Hi, > > below are my comments about the -04 draft (top-down read, focusing on > WebDAV/HTTP questions with little Calendaring specific checks): > > Best regards, Julian > > -- > > 04-C01 Section 1.1.1 > > > > > A few terminology problems here: > > "WebDAV is an extension to the HTTP/1.1 [4] protocol, therefore its URLs > are HTTP URLs." > > That's a bit misleading, as there are other URLs used within WebDAV > which aren't HTTP URLs, for instance lock tokens. > > "If HTTP GET can be used to represent a calendar object..." > > GET doesn't represent objects, it *retrieves* representations of objects. > > In general, this probably should be re-organized into two parts: > > 1) why it's good to have retrievable URIs for calendar objects, thus HTTP > 2) why it's good to re-use existing HTTP extensions, thus WebDAV > > > 04-C03 Section 1.1.8 > > > > > "Dead properties are client-controlled properties, where the namespace, > name and value are entirely controlled by the client. However, the > server is required to store these properties and return them, if > requested, in PROPFIND queries for individual resources or in listings > of collection contents." > > Why: "however"? > > "Some servers support text searching on all dead properties through the > DASL extensions (a work in progress) [TODO: REF]. Dead properties can > also be used in reports." > > Missing reference. The informative text about the advantages of CalDAV (i.e., sections 1.1.*) has been removed from the draft. > > > 04-C04, Section 6 > > > > > "Calendars and individual calendar objects may all be created by either > the CalDAV client or by the CalDAV server." > > This is misleading. It's always the server thst creates objects. If this > is about who *initiates* the creation, this should be clarified. The wording was changed. > > > 04-C05, Section 6.1 > > > > > "The successful response to MKCALENDAR is typically 201 (Created)." > > What is "typically" supposed to mean? Please either be precise here or > remove that sentence (thus RFC2616 applies). > > "Note that there is no semantic value in any other part of a calendar > name (or a resource name, other than possibly the file extension)." > > No, not even the file extension. Neither HTTP nor WebDAV have a notion > of "file extension". > > "Thus, a calendar collection may be called "calendar", "cal", > "Calendario" and so on. It's the properties of the resource that define > what it is, not the name."" > > It's the DAV:resourcetype property, right? Why not simply say so? The MKCALENDAR section has been reshaped to follow the same format as MKWORKSPACE and MKACTIVITY in DeltaV. > > > 04-C06, Section 6.3 > > > > > The example given (resource created at a different URI) seems to violate > HTTP semantics: if PUT doesn't actually create a resource at the > Request-URI, a status code of 201 (actually any 2xx code) seems to be > wrong. This issue is not addressed yet. > > > 04-C07, Section 7 > > > > > "A server supporting CalDAV MUST support additional properties on > principal resources if these principals are associated with calendars. > In addition, certain properties are required on calendars to link to > principal resources. These properties are defined in the properties > section." > > This additional requirement will make some existing RFC3744 > implementations unable to conform to this spec. I think this is a > problem, and an alternate solution (not requiring custom properties on > principal resources) should be discussed. This paragraph has been removed from this section. The section "Additional Principal Properties" now says that support for CALDAV:calendar-URL is RECOMMENDED. > > > 04-C08, Section 9 > > > > > It's unclear why the discussion about PUT vs PROPPATCH vs SCHEDULE is > still in when the document indeed defines a SCHEDULE method in section 9.1. > > (editorial note: it would be nice if editorial comments and notes would > use RFC2629's element for better readability) Editorial comments are now specified in elements. > > > 04-C09, Section 9.1 > > > > > Why is the title "SCHEDULE method for WebDAV"? What does it make a > method for WebDAV, rather than an HTTP method? What's the difference? > > Also, it would be good if the method description would be a bit more > formal in defining the new HTTP request headers (ABNF?). (forward > reference to section 10?) > > > 04-C10, Section 9.1.1 > > > > > There seems be some confusion about when to return a 207 and when not. > For instance, I'd expect a malformed request body to result in a HTTP > status of 400. Also, the multistatus response for a successful request > needs to be more formally defined (such as: must contain response > elements for each Recipient reuqest header URI). > The scheduling part of CalDAV has been moved into a separate draft. Those issues will be addressed later. > > 04-C11, Section 11 > > > > > Which XML namespace are the has-* properties in? All the has-* properties have been removed. The CALDAV:calendar-query report allows one to request that the actual value of some properties not be returned (if the "novalue" attribute is set to "yes" in the CALDAV:prop element). > > > 04-C12, Section 12 > > > > > "Note that the XML Schema declarations used in this document are > incomplete, in that they do not include namespace information." > > There are no XML Schema declarations in this document. Right. Changed to "XML declarations" and moved into an earlier section. > > > 04-C13, Section 12.2 > > > > > I think it would be good if the document would explain what this > property is used for. The calscale property has been removed. > > > 04-C14, Section 13 > > > > > "Generally, if no appropriate value is known for these properties, the > properties SHOULD exist but be blank." > > This seems to be inconsistent with other WebDAV properties (which will > simply not be present when not applicable. Right. Fixed. > > Also need to specify whether these are live or dead properties, and if > they are live, whether protected or not. Furthermore, if live the spec > should define whether they should appear on propfind/allrop (same > applies to the properties defined in section 12). Not done yet. > > > 04-C15, Section 15 > > > > > The introduction should point to the normative definition of the REPORT > method (RFC3253, 3.6) Right. I've copied the introduction that WebDAV ACL has for the REPORT method. > and it also needs to define whether the > DAV:expand-property-report (3.8) is mandatory (it is in RFC3253 and > RFC3744). Done. > > Also, error marshalling shouldn't be repeated (is it the same as in > RFC3253? If not, why?), and usage of the DAV:error response element > needs to be consistent with RFC3253. We have started to document our preconditions, postconditions in draft -05. Work in progress. > > > 04-C16, Section 15.1 > > > > > Should define the role of the Depth request header when applied to a > collection resource. Not done yet. > > > 04-C17, Section 15.2 > > > > > There doesn't seem to be a definition of the calendar-query-result > request element. That text got lost in the editing process. It was later sent on this mailing list. > > It's a bit unclear why the spec needs to extend multistatus, that is, > why the requested ical information can't be returned in the form of > promoted properties (I think this would greatly simplify the spec). In Section 12.11 of RFC 2518 it says: The prop XML element is a generic container for properties defined on resources. All elements inside a prop XML element MUST define properties related to the resource. No other elements may be used inside of a prop element. Given that the value of calendar-query-result (renamed to calendar-data in draft -05) depends on the request body of a REPORT, could we really claim that it "defines properties related to the resource"? I guess if you were to request this "property" with PROPFIND we could simply return the full iCalendar object, i.e., with all its components and properties. Would making this element a property be considered as an abuse? Any opinion? > > > 04-E01, References > > The following references are not used (RFC2629-wise) in the text: > > WARNING: unused reference 'RFC3339' > WARNING: unused reference 'RDF-ICAL' > WARNING: unused reference 'I-D.reschke-webdav-search' All unused references were removed. X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from rgminet03.oracle.com (rgminet03.oracle.com [148.87.122.32]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1B5E7aa029876 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 10 Feb 2005 21:14:07 -0800 Received: from rgminet03.oracle.com (localhost [127.0.0.1]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1B5E1EM011359 for ; Fri, 11 Feb 2005 00:14:01 -0500 Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet03.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1B58EiB006274 for ; Fri, 11 Feb 2005 00:11:18 -0500 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1B58EvO004558 for ; Thu, 10 Feb 2005 22:08:14 -0700 Received: from [192.168.1.200] (dhcp-amer-csvpn-gw1-141-144-64-102.vpn.oracle.com [141.144.64.102]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j1B5841t004480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Feb 2005 22:08:05 -0700 Message-ID: <420C3DB1.40500@oracle.com> Date: Fri, 11 Feb 2005 00:08:01 -0500 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] draft-dusseault-caldav-05.txt X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 05:14:13 -0000 We've just submitted CalDAV draft -05 to the IETF. It's already available at the following URL: http://ietf.cse.ucsc.edu/caldav/draft-dusseault-caldav-05.txt B.1 Changes in -05 a. Removed a lot of non-normative text. b. Removed property promotion/demotion requirements. c. Removed calendar-owner and cal-scale properties. d. Removed 'ical' prefix/text from element names. e. Relaxed WebDAV Class 2 (locking) requirement to a MAY. f. Relaxed MKCALENDAR requirement to a SHOULD. g. Moved the XML Namespace section in the Introduction. h. Added CALDAV: prefix to CalDAV XML elements in the text. i. Added CALDAV:calendar-multiget report. j. Added CALDAV:free-busy-query report. k. Added CALDAV:calendar-description property. l. Changed CALDAV:calendar-query-result element name to CALDAV:calendar-data m. Added description and examples of handling timezones. n. Added mandatory "start" and "end" attributes to the CALDAV:expand-recurrence-set element. o. Added three CalDAV OPTIONS requests. p. Grouped XML Element declarations in a separate section. We are planning to submit draft-desruisseaux-caldav-sched-00.txt in the coming weeks. Cheers, Bernard X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1B0CVaZ001877 for ; Thu, 10 Feb 2005 16:12:31 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf-caldav DevList From: Lisa Dusseault Date: Thu, 10 Feb 2005 16:12:19 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] CalDAV home page X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 00:12:43 -0000 I've put together a rough "home page" for CalDAV, pretty clearly based on the WebDAV resources page (I stole all the HTML, in fact) http://ietf.webdav.org/caldav/ Suggestions welcome Lisa X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j1A5UlaZ029649 for ; Wed, 9 Feb 2005 21:30:47 -0800 Received: from unknown (HELO ?192.168.0.100?) (dave.thewlis@sbcglobal.net@69.107.151.197 with plain) by smtp813.mail.sc5.yahoo.com with SMTP; 10 Feb 2005 05:30:46 -0000 Message-ID: <420AF17F.1080508@calconnect.org> Date: Wed, 09 Feb 2005 21:30:39 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Report on Calconnect Roundtable II; advance notice of Roundtable III - The Calendaring and Scheduling Consortium X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2005 05:30:49 -0000 This note is going to the ietf-caldav and ietf-calsify mailing lists, which means that many people will get it twice. My apologies; there seem to be enough people on one or the other but not both to require separate sends. ---------------- The Calendaring and Scheduling Consortium, also known as CalConnect, held its first formal Roundtable event together with an Interop in Seattle, Washington on 11-13 January, hosted by the University of Washington. A report on Roundtable II has been posted to the Calconnect website at www.calconnect.org: choose "Roundtable II" from the sidebar or go to www.calconnect.org/roundtable2.html. The public report on the Interop event has been posted on the website under Past Interops, where you can also locate information and results from previous Calconnect Interops. The next Consortium Roundtable and Interop will be 1-3 June, 2005, hosted by Duke University in Durham, North Carolina. Please visit our website at www.calconnect.org for further information about the Consortium including events, technical committees, and Interops. Please contact me with any questions or for information about joining the Consoritum. Best Regards, Dave Thewlis, Executive Director The Calendaring and Scheduling Consortium +1 707 840 9391 voice +1 707 498 2238 cell X-Envelope-From: Doug@Royer.com X-Envelope-To: Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j1208Taa028900 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 1 Feb 2005 16:08:30 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.12.2/8.12.2) with ESMTP id j1208E7J015007 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Feb 2005 16:08:16 -0800 Message-ID: <420019ED.4060701@Royer.com> Date: Tue, 01 Feb 2005 17:08:13 -0700 From: Doug Royer Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Mosedale Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML anguage bindings References: <41F99422.7040906@mozilla.org> <41F9FD3A.4020608@gmx.de> <41FACCE1.2070703@mozilla.org> <41FFF387.8050004@mozilla.org> In-Reply-To: <41FFF387.8050004@mozilla.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000501090708000301000801" X-Royer.com-MailScanner-Information: Please contact SiteAdmin@Royer.com for more information X-Royer.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-caldav List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2005 00:08:33 -0000 This is a cryptographically signed message in MIME format. --------------ms000501090708000301000801 Content-Type: multipart/mixed; boundary="------------090308020105070000070208" This is a multi-part message in MIME format. --------------090308020105070000070208 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > I think you're misunderstanding the concept of a native-language > binding: the parsing for XML element names can't be separate from the > language parsing itself. That is, XML element names are parsed as > member variable names in the context of normal code. So in JS, for > example, this means that XML element names that are compatible with JS > property names can be addressed directly as a property on a JS object, > but names with (eg) a minus in them cannot. This is likely to be true > of any native XML binding to almost any language: minus is an operator > (and therefore not part of a valid variable name) in most popular > languages today. I can parse XML with C/C++/Java/PHP/Python/Perl and other languages that also do not allow variable names to contain a dash. In all cases you have to store your XML names you parse in a collection that allows those names for exactly that reason. And every language that I have used has a SAX or a SAX like API, you can get to all of those names and their data. Why is JS different? It sounds like you want to make XML element name the JS variable names. And this debate took place on the XML mailing lists years ago and most considered it not a valid argument as it would restrict XML element names to a worst case sub-set of a huge and unknown number of programming languages. This debate also took place on the CALSCH mailing list for parsing iCalendar property names. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090308020105070000070208 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090308020105070000070208-- --------------ms000501090708000301000801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAyMDAwODEzWjAjBgkqhkiG9w0BCQQxFgQU4sMbt6VcY7OvBzotmmM+ OPUdOcMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEARPIe2PU2+lFJpnxE5EPgtBRTMJ91dlrTZnHENSSu0D6GwDdBSQz+eJm/Dn0BajEz Dn1CPUxKyYTkYdPsGDMgYoTc55DZZHB2iXHkVe7yq4KLBiR8WDg7LtmMfI8sjr1K2aqH+8a3 QtCMEQXy6DRHbU4V2JuTlXq/FPncvoEJmmzh9Ju2YabJuN7XPBD7Um2GRe7cM8g/J2st8G3n fQk9GXrQFH9qP643nIg0E6eOqj0NbFyKQXUbuKj7qJyxekX4rLcShSPdHkKGGMv6S72sFVn4 Xn+Vook0jr5ABYM7L2uBMrZiVL5r8kE+949AhjNLFv/wRhdjH6MGKllpuKvFcAAAAAAAAA== --------------ms000501090708000301000801-- X-Envelope-From: dmose@mozilla.org X-Envelope-To: Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j11LOgaZ006958 for ; Tue, 1 Feb 2005 13:24:42 -0800 Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id j11LObV1068957; Tue, 1 Feb 2005 13:24:38 -0800 (PST) (envelope-from dmose@mozilla.org) Received: from [192.168.1.109] (dsl081-050-187.sfo1.dsl.speakeasy.net [64.81.50.187]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j11LOJWR014420; Tue, 1 Feb 2005 13:24:21 -0800 (PST) (envelope-from dmose@mozilla.org) Message-ID: <41FFF387.8050004@mozilla.org> Date: Tue, 01 Feb 2005 13:24:23 -0800 From: Dan Mosedale User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess Subject: Re: [Ietf-caldav] hyphens in element names problematic for XML language bindings References: <41F99422.7040906@mozilla.org> <41F9FD3A.4020608@gmx.de> <41FACCE1.2070703@mozilla.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-caldav X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2005 21:24:43 -0000 Helge Hess wrote: > On 29. Jan 2005, at 00:38 Uhr, Dan Mosedale wrote: > >> In my mind, the issue is not a matter of optimization, but of >> readable code. > > But isn't that the same reason why dashes are used in the protocol? > XML is supposed to be human readable/writable for various reasons and > slashes help with that. Fair enough. However, I suspect we can come up with a list of elements names for the caldav context that are similarly readable to our current set, which is really what counts here, I think. >> My experience has been that less readable code tends to have more >> bugs. As you point out, it's too late to fix existing cases of this >> in WebDAV itself, but by changing the new CalDAV-specific elements, >> we can at least avoid making the problem worse. If we do this, then >> implementors end up having fewer code statements that need to use >> hard-to-read escape syntaxes. This should lead, I suspect, to at >> least slightly less buggy code in the CalDAV implementations written >> in such environments, which is good for the community as a whole. > > > It makes it easier for your specific implementation of the XML parser > which may or may not be a worthwhile reason (IMHO its not). > > Personally I would assume that your XML parser could be easily > enhanced to escape dashes with eg underlines prior calling back to the > application? Since dashes are regular XML, I would assume that this > should be in the parser anyway? I think you're misunderstanding the concept of a native-language binding: the parsing for XML element names can't be separate from the language parsing itself. That is, XML element names are parsed as member variable names in the context of normal code. So in JS, for example, this means that XML element names that are compatible with JS property names can be addressed directly as a property on a JS object, but names with (eg) a minus in them cannot. This is likely to be true of any native XML binding to almost any language: minus is an operator (and therefore not part of a valid variable name) in most popular languages today. Having the language binding use an underscore instead can't work, because underscore is also valid in XML element names, so there would be no way to disambiguate. Dan