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 j2T20baa017954 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 28 Mar 2005 18:00:37 -0800 In-Reply-To: <42437F8A.4020000@rpi.edu> References: <42437F8A.4020000@rpi.edu> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0d1056a974c2b4576b43226d4a23f642@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Event creation Date: Mon, 28 Mar 2005 18:00:30 -0800 To: Mike Douglass X-Mailer: Apple Mail (2.619.2) 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, 29 Mar 2005 02:00:41 -0000 Hi Mike, We have had some discussion of this, e.g. in http://lists.osafoundation.org/pipermail/ietf-caldav/2005-March/ 000324.html. I agree it's harder for servers to do, but it's not that much harder -- the server just needs to keep a list of the URLs that it assigned based on the client choices, and map those URLs to its internal identifiers. This is one more data table and a tiny fraction of the overall data that is stored. Lisa On Mar 24, 2005, at 7:03 PM, Mike Douglass wrote: > First an apology: > As a late entrant to the caldav world (since calconnect Jan 2005) I've > not been a party to the ongoing discussions so forgive me for > reopening old discussions. I'll also point out I'm a consumer rather > than creator of protocols so please excuse any imprecision on my part. > > I am implementing caldav for the UW calendar so I guess I am bringing > a server side perspective to things. > > Is it possible to agree (or at least accept) that requiring servers to > accept any URI they are given will make caldav implementations more > difficult than they need be. > > I for one believe the POST + 201 approach allowing the server to > determine the eventual resource name is a reasonable approach given > that the PUT + 201 appears to be doomed. > > Even for a simple server implementation, there are reasons why the > client supplied name may be unacceptable. If each event is stored in a > file the servers file system may disallow the proposed name. For > systems which exists already, events are already identified by other > schemes, the caldav implementor may be unable to change that so any > protocol which forces the server to accept arbitrary names for new > events requires implementors to build new mapping schemes just for > caldav. > > Some of the proposed alternatives involve redirects or maybe an extra > trip to the server and there have been suggestions that this may cause > efficency or performance problems. > > Firstly I'd point out that redirects after a POST are now considered > the appropriate way of building applications, they avoid a number of > problems and I don't believe many people are worrying too much about > response times or performance issues > (http://www.theserverside.com/articles/article.tss? > l=RedirectAfterPost2 for a discussion) > > Second, the client I tried (which doesn't support draft-5) does a PUT > followed by a PROPFIND so already does two trips. Other clients would > probably do the same. If the client wants an accurate copy of what the > server has created it is probably going to have to retrieve the event. > I have to believe calendar servers are not going to store exactly what > the client sends, they will add other information and possibly change > some - we're not dealing with a file storage mechanism but an > information storage system. > > I'd suggest that some mechanism which allowed the client to send a > representation of a new event followed by a response containing the > server view of that new event is likely to be more efficient. > > In addition, even if the calendar is on the same machine as the mail > servers, human initiated activity is just background noise. We're a > small institution but we get in the order of 650,000 pop requests a > day on one machine, that doesn't count imap, smtp or all the other > rejected connection attempts. 50, 100, 200 people responding to an > invitation over a period of time doesn't even register, even if it > takes 3 trips. > > As for the form of the names, clients presumably already have to > accept the URI that a server produces. We already have 1000s of events > with a naming scheme, caldav clients will accept those events with > those URI's - they have to - they can't rename every event. When a new > event is created the name the server chooses has to be acceptable to > the client. > > In any case, given the stateless nature of caldav/webdav accepting and > storing arbitrary URI's involves a db update before we respond - much > more of a performance problem than a redirect. > > The alternative of a server accepting any URI the client chooses is a > significant implementation problem at the server side. Now when we > retrieve events for a given calendar we also have to maintain and > search a table to see if some client(s) out there provided us with > events and return those names as the URI. We also have to do more > complex searches to retrieve events. > > It's bad enough if we have access to the server code itself. It will > be much worse for those trying to develop a caldav server for a > preexisting calendar implementation. Without the ability to tell the > client what the new resource is named a caldav implementation requires > db tables and a lot of searching. With that ability caldav server > implementations can use the existing calendar server with no > subsidiary tables. > > -- > > Mike Douglass douglm@rpi.edu > Senior Systems Programmer > Communication & Collaboration Technologies 518 276 6780(voice) > 2809 > (fax) > Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: douglm@rpi.edu X-Envelope-To: Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2P33iaa007316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Mar 2005 19:03:45 -0800 Received: from [192.168.0.101] (vpn-869.nss.rpi.edu [128.113.211.119]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j2P33hng016308 for ; Thu, 24 Mar 2005 22:03:44 -0500 Message-ID: <42437F8A.4020000@rpi.edu> Date: Thu, 24 Mar 2005 22:03:38 -0500 From: Mike Douglass User-Agent: Mozilla Thunderbird 1.0 (X11/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-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 X-Spam-Score: 0 () Subject: [Ietf-caldav] Event creation 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 Mar 2005 03:03:48 -0000 First an apology: As a late entrant to the caldav world (since calconnect Jan 2005) I've not been a party to the ongoing discussions so forgive me for reopening old discussions. I'll also point out I'm a consumer rather than creator of protocols so please excuse any imprecision on my part. I am implementing caldav for the UW calendar so I guess I am bringing a server side perspective to things. Is it possible to agree (or at least accept) that requiring servers to accept any URI they are given will make caldav implementations more difficult than they need be. I for one believe the POST + 201 approach allowing the server to determine the eventual resource name is a reasonable approach given that the PUT + 201 appears to be doomed. Even for a simple server implementation, there are reasons why the client supplied name may be unacceptable. If each event is stored in a file the servers file system may disallow the proposed name. For systems which exists already, events are already identified by other schemes, the caldav implementor may be unable to change that so any protocol which forces the server to accept arbitrary names for new events requires implementors to build new mapping schemes just for caldav. Some of the proposed alternatives involve redirects or maybe an extra trip to the server and there have been suggestions that this may cause efficency or performance problems. Firstly I'd point out that redirects after a POST are now considered the appropriate way of building applications, they avoid a number of problems and I don't believe many people are worrying too much about response times or performance issues (http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2 for a discussion) Second, the client I tried (which doesn't support draft-5) does a PUT followed by a PROPFIND so already does two trips. Other clients would probably do the same. If the client wants an accurate copy of what the server has created it is probably going to have to retrieve the event. I have to believe calendar servers are not going to store exactly what the client sends, they will add other information and possibly change some - we're not dealing with a file storage mechanism but an information storage system. I'd suggest that some mechanism which allowed the client to send a representation of a new event followed by a response containing the server view of that new event is likely to be more efficient. In addition, even if the calendar is on the same machine as the mail servers, human initiated activity is just background noise. We're a small institution but we get in the order of 650,000 pop requests a day on one machine, that doesn't count imap, smtp or all the other rejected connection attempts. 50, 100, 200 people responding to an invitation over a period of time doesn't even register, even if it takes 3 trips. As for the form of the names, clients presumably already have to accept the URI that a server produces. We already have 1000s of events with a naming scheme, caldav clients will accept those events with those URI's - they have to - they can't rename every event. When a new event is created the name the server chooses has to be acceptable to the client. In any case, given the stateless nature of caldav/webdav accepting and storing arbitrary URI's involves a db update before we respond - much more of a performance problem than a redirect. The alternative of a server accepting any URI the client chooses is a significant implementation problem at the server side. Now when we retrieve events for a given calendar we also have to maintain and search a table to see if some client(s) out there provided us with events and return those names as the URI. We also have to do more complex searches to retrieve events. It's bad enough if we have access to the server code itself. It will be much worse for those trying to develop a caldav server for a preexisting calendar implementation. Without the ability to tell the client what the new resource is named a caldav implementation requires db tables and a lot of searching. With that ability caldav server implementations can use the existing calendar server with no subsidiary tables. -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 X-Envelope-From: brianboy@mac.com X-Envelope-To: Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2P1txaZ032747 for ; Thu, 24 Mar 2005 17:55:59 -0800 Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id j2P1txev002015 for ; Thu, 24 Mar 2005 17:55:59 -0800 (PST) Received: from [17.216.20.244] (a17-216-20-244.apple.com [17.216.20.244]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j2P1twb3028557 for ; Thu, 24 Mar 2005 17:55:59 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 24 Mar 2005 17:55:57 -0800 From: BrianBoy To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.034 () SUB_FREE_OFFER X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Free busy query: rephrased 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 Mar 2005 01:56:00 -0000 According to the scheduling draft a calendar-time-range report can be used to see if a calendar owner is free similarly free-busy-query report which acts on a calendar collection to return the free busy times of that collection. The problem here is if meeting has a high number of participants a free-busy query for every participants calendar will be an overkill and induce delays from the client side . Is is possible to do a single free busy query to find out the freebusy time for multiple attends of a meeting ? . If not, a special type of report is required that is not a calendar collection specific but honors an iTip body, or attendee info passed through the report header. Brian X-Envelope-From: brianboy@mac.com X-Envelope-To: Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2OJRIaZ004783 for ; Thu, 24 Mar 2005 11:27:18 -0800 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id j2OJRImS003251 for ; Thu, 24 Mar 2005 11:27:18 -0800 (PST) Received: from [17.216.20.244] (a17-216-20-244.apple.com [17.216.20.244]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j2OJRHf4002451 for ; Thu, 24 Mar 2005 11:27:17 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 24 Mar 2005 11:27:15 -0800 From: BrianBoy To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.034 () SUB_FREE_OFFER X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Free-Busy Report Query 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, 24 Mar 2005 19:27:18 -0000 I have a couple of questions on the CALDAV Free busy queries, Is is possible to do a single free busy query to find out the freebusy time for multiple attends in a meeting ? . If so where is the multiple attendee u information specified in the body ? Because most of the report request queries are only using dav xml tags instead of a iCalendar type info . But the responses do have icalendar(iTip) information. Can some one show me a simple free busy report request query with multiple attendees. Brian X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2O0oaaZ011077 for ; Wed, 23 Mar 2005 16:50:36 -0800 Received: from thare.comcast.net (pcp03614086pcs.micske01.fl.comcast.net[68.84.31.44]) by comcast.net (rwcrmhc14) with SMTP id <2005032400503001400aolace>; Thu, 24 Mar 2005 00:50:30 +0000 Message-Id: <6.2.1.2.0.20050323194842.01cc9140@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 19:50:33 -0500 To: ietf-caldav@osafoundation.org From: Tim Hare Subject: Fwd: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.379 (**) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,URIBL_SBL 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: Thu, 24 Mar 2005 00:50:37 -0000 Forgive the duplicate post, I meant for the first sentence to read: RFC2739 addressed calendar properties in LDAP, perhaps you could build on, or use that? And the link should be: http://www.ietf.org/rfc/rfc2739.txt The "official" link. >Date: Wed, 23 Mar 2005 19:48:22 -0500 >To: ietf-caldav@osafoundation.org> >From: Tim Hare >Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation > >RFC2739 addressed this for iCalendar, perhaps you could build on that? > >http://www.faqs.org/rfcs/rfc2739.html > > > >At 04:28 PM 3/23/2005, BrianBoy wrote: >>Thanks. It is clear now . >> >>Is the source code for the server available in Some CVS site where I can >>download etc? >> >>Brian. >> >> >> >>On 3/23/05 12:50 PM, "Cyrus Daboo" wrote: >> >> > Hi, >> > >> > --On Wednesday, March 23, 2005 12:23 -0800 BrianBoy >> > wrote: >> > >> >> How will a caldav client discover the caldav server structure. Since >> >> caldav needs to operate on urls for eg. >> >> >> >> www.mydomain.com/caldav/users/brian/calendar >> >> >> >> Once the URL is known according to the draft it is possible to know it is >> >> a calendar resource by checking the property. >> >> >> >> Or does the client browse through the various collections to find a users >> >> calendar collection.? >> > >> > In my current client/server implementation what I have done is to >> designate >> > a portion of the URI space on the server as being the 'calendar store': >> > >> > >> > >> > The client gets configured with that URI and that forms the root of a >> > hierarchical browser that does PROPFINDs to display a hierarchy of >> > collections/calendars to the user. Below that URI I currently have >> 'public' >> > and 'users' collections, and with 'users' are collections for each >> user id. >> > Each user then maintains their own calendars within that. >> > >> > This model mimics what would typically be done on an IMAP mail server. It >> > would be nice if there were a way for the client to discover the relevant >> > portions of the URI space on the server (as per the IMAP NAMESPACE >> > extension) but the CalDAV authors have had varying opinions on whether >> that >> > is needed and how it should be done... >> > >> >> how would it even know that brian's calendar is in this url? how >> would it >> >> know if brian's url changed? >> > >> > See section 7.2 of the current CalDAV draft. Basically we define a new >> > property on principal resources that indicates the primary location of >> > calendars for that principal. >> > >> > In terms of discovering what URI to use for some random user - that's out >> > of scope for CalDAV itself. That's more of a service discovery type >> problem >> > and is related to how you go about defining a 'calendar address' for a >> > particular user. One simple solution is to say calendar addresses are >> email >> > addresses so to find my calendar address you would find the caldav server >> > at my domain then query for my principal resource and look at the property >> > there. >> > >> >> >> >> 2) Does anybody out there have a caldav implementation on top of >> slide . I >> >> know there was a lot of discussion on this. I am wondering if a version >> >> exist? If it did where can I get it? >> > >> > Our current CalDAV prototype server (on top of Slide) is available for >> > public access/testing at the URI above. This is not complete in terms of >> > implementing the current spec (e.g. we have not implemented the free-busy >> > report yet), but it should be OK for preliminary tests. You will need to >> > use user id and password both set to 'guest' to access the server. >> >>_______________________________________________ >>Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >>See http://ietf.webdav.org/caldav/ for more CalDAV resources >>http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > >Tim Hare >Interested Bystander, Non-Inc. Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2O0mRaZ010918 for ; Wed, 23 Mar 2005 16:48:27 -0800 Received: from thare.comcast.net (pcp03614086pcs.micske01.fl.comcast.net[68.84.31.44]) by comcast.net (rwcrmhc11) with SMTP id <2005032400482101300e5k2pe>; Thu, 24 Mar 2005 00:48:21 +0000 Message-Id: <6.2.1.2.0.20050323194542.01d01548@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 23 Mar 2005 19:48:22 -0500 To: ietf-caldav@osafoundation.org From: Tim Hare Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.379 (**) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,URIBL_SBL 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: Thu, 24 Mar 2005 00:48:29 -0000 RFC2739 addressed this for iCalendar, perhaps you could build on that? http://www.faqs.org/rfcs/rfc2739.html At 04:28 PM 3/23/2005, BrianBoy wrote: >Thanks. It is clear now . > >Is the source code for the server available in Some CVS site where I can >download etc? > >Brian. > > > >On 3/23/05 12:50 PM, "Cyrus Daboo" wrote: > > > Hi, > > > > --On Wednesday, March 23, 2005 12:23 -0800 BrianBoy > > wrote: > > > >> How will a caldav client discover the caldav server structure. Since > >> caldav needs to operate on urls for eg. > >> > >> www.mydomain.com/caldav/users/brian/calendar > >> > >> Once the URL is known according to the draft it is possible to know it is > >> a calendar resource by checking the property. > >> > >> Or does the client browse through the various collections to find a users > >> calendar collection.? > > > > In my current client/server implementation what I have done is to designate > > a portion of the URI space on the server as being the 'calendar store': > > > > > > > > The client gets configured with that URI and that forms the root of a > > hierarchical browser that does PROPFINDs to display a hierarchy of > > collections/calendars to the user. Below that URI I currently have 'public' > > and 'users' collections, and with 'users' are collections for each user id. > > Each user then maintains their own calendars within that. > > > > This model mimics what would typically be done on an IMAP mail server. It > > would be nice if there were a way for the client to discover the relevant > > portions of the URI space on the server (as per the IMAP NAMESPACE > > extension) but the CalDAV authors have had varying opinions on whether that > > is needed and how it should be done... > > > >> how would it even know that brian's calendar is in this url? how would it > >> know if brian's url changed? > > > > See section 7.2 of the current CalDAV draft. Basically we define a new > > property on principal resources that indicates the primary location of > > calendars for that principal. > > > > In terms of discovering what URI to use for some random user - that's out > > of scope for CalDAV itself. That's more of a service discovery type problem > > and is related to how you go about defining a 'calendar address' for a > > particular user. One simple solution is to say calendar addresses are email > > addresses so to find my calendar address you would find the caldav server > > at my domain then query for my principal resource and look at the property > > there. > > > >> > >> 2) Does anybody out there have a caldav implementation on top of slide . I > >> know there was a lot of discussion on this. I am wondering if a version > >> exist? If it did where can I get it? > > > > Our current CalDAV prototype server (on top of Slide) is available for > > public access/testing at the URI above. This is not complete in terms of > > implementing the current spec (e.g. we have not implemented the free-busy > > report yet), but it should be OK for preliminary tests. You will need to > > use user id and password both set to 'guest' to access the server. > >_______________________________________________ >Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >See http://ietf.webdav.org/caldav/ for more CalDAV resources >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: brianboy@mac.com X-Envelope-To: Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2NLSsaZ031518 for ; Wed, 23 Mar 2005 13:28:54 -0800 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id j2NLSrKi017168; Wed, 23 Mar 2005 13:28:53 -0800 (PST) Received: from [17.216.20.244] (a17-216-20-244.apple.com [17.216.20.244]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j2NLSpUl019649; Wed, 23 Mar 2005 13:28:52 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 23 Mar 2005 13:28:49 -0800 Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation From: BrianBoy To: Cyrus Daboo , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.629 () URIBL_SBL 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: Wed, 23 Mar 2005 21:28:55 -0000 Thanks. It is clear now . Is the source code for the server available in Some CVS site where I can download etc? Brian. On 3/23/05 12:50 PM, "Cyrus Daboo" wrote: > Hi, > > --On Wednesday, March 23, 2005 12:23 -0800 BrianBoy > wrote: > >> How will a caldav client discover the caldav server structure. Since >> caldav needs to operate on urls for eg. >> >> www.mydomain.com/caldav/users/brian/calendar >> >> Once the URL is known according to the draft it is possible to know it is >> a calendar resource by checking the property. >> >> Or does the client browse through the various collections to find a users >> calendar collection.? > > In my current client/server implementation what I have done is to designate > a portion of the URI space on the server as being the 'calendar store': > > > > The client gets configured with that URI and that forms the root of a > hierarchical browser that does PROPFINDs to display a hierarchy of > collections/calendars to the user. Below that URI I currently have 'public' > and 'users' collections, and with 'users' are collections for each user id. > Each user then maintains their own calendars within that. > > This model mimics what would typically be done on an IMAP mail server. It > would be nice if there were a way for the client to discover the relevant > portions of the URI space on the server (as per the IMAP NAMESPACE > extension) but the CalDAV authors have had varying opinions on whether that > is needed and how it should be done... > >> how would it even know that brian's calendar is in this url? how would it >> know if brian's url changed? > > See section 7.2 of the current CalDAV draft. Basically we define a new > property on principal resources that indicates the primary location of > calendars for that principal. > > In terms of discovering what URI to use for some random user - that's out > of scope for CalDAV itself. That's more of a service discovery type problem > and is related to how you go about defining a 'calendar address' for a > particular user. One simple solution is to say calendar addresses are email > addresses so to find my calendar address you would find the caldav server > at my domain then query for my principal resource and look at the property > there. > >> >> 2) Does anybody out there have a caldav implementation on top of slide . I >> know there was a lot of discussion on this. I am wondering if a version >> exist? If it did where can I get it? > > Our current CalDAV prototype server (on top of Slide) is available for > public access/testing at the URI above. This is not complete in terms of > implementing the current spec (e.g. we have not implemented the free-busy > report yet), but it should be OK for preliminary tests. You will need to > use user id and password both set to 'guest' to access the server. 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 j2NKoAaa028795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Mar 2005 12:50:11 -0800 Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2NKZT6g011382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2005 15:35:29 -0500 Date: Wed, 23 Mar 2005 15:50:05 -0500 From: Cyrus Daboo To: BrianBoy , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.0a7 (Win32) 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.629 () URIBL_SBL 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: Wed, 23 Mar 2005 20:50:12 -0000 Hi, --On Wednesday, March 23, 2005 12:23 -0800 BrianBoy wrote: > How will a caldav client discover the caldav server structure. Since > caldav needs to operate on urls for eg. > > www.mydomain.com/caldav/users/brian/calendar > > Once the URL is known according to the draft it is possible to know it is > a calendar resource by checking the property. > > Or does the client browse through the various collections to find a users > calendar collection.? In my current client/server implementation what I have done is to designate a portion of the URI space on the server as being the 'calendar store': The client gets configured with that URI and that forms the root of a hierarchical browser that does PROPFINDs to display a hierarchy of collections/calendars to the user. Below that URI I currently have 'public' and 'users' collections, and with 'users' are collections for each user id. Each user then maintains their own calendars within that. This model mimics what would typically be done on an IMAP mail server. It would be nice if there were a way for the client to discover the relevant portions of the URI space on the server (as per the IMAP NAMESPACE extension) but the CalDAV authors have had varying opinions on whether that is needed and how it should be done... > how would it even know that brian's calendar is in this url? how would it > know if brian's url changed? See section 7.2 of the current CalDAV draft. Basically we define a new property on principal resources that indicates the primary location of calendars for that principal. In terms of discovering what URI to use for some random user - that's out of scope for CalDAV itself. That's more of a service discovery type problem and is related to how you go about defining a 'calendar address' for a particular user. One simple solution is to say calendar addresses are email addresses so to find my calendar address you would find the caldav server at my domain then query for my principal resource and look at the property there. > > 2) Does anybody out there have a caldav implementation on top of slide . I > know there was a lot of discussion on this. I am wondering if a version > exist? If it did where can I get it? Our current CalDAV prototype server (on top of Slide) is available for public access/testing at the URI above. This is not complete in terms of implementing the current spec (e.g. we have not implemented the free-busy report yet), but it should be OK for preliminary tests. You will need to use user id and password both set to 'guest' to access the server. -- Cyrus Daboo X-Envelope-From: bcm@osafoundation.org X-Envelope-To: Received: from [10.0.1.8] (c-67-170-198-213.client.comcast.net [67.170.198.213]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2NKWxaa027423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Mar 2005 12:33:00 -0800 Message-ID: <4241D27B.3040508@osafoundation.org> Date: Wed, 23 Mar 2005 12:32:59 -0800 From: Brian Moseley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Question on Discovery and CalDav Implementation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 23 Mar 2005 20:33:00 -0000 BrianBoy wrote: > how would it even know that brian's calendar is in this url? how would it > know if brian's url changed? the million dollar question :) i don't believe it has been (or is planned to be) addressed by the spec, as Lisa and i have had several conversations on how users can communicate their calendar URLs to each other. > 2) Does anybody out there have a caldav implementation on top of slide . I > know there was a lot of discussion on this. I am wondering if a version > exist? If it did where can I get it? we're working on a CalDAV implementation at OSAF, of course. i've been prototyping with both Slide and Jackrabbit (the JSR 170 reference implementation), but i haven't chosen which we'll use yet (tho i'm leaning heavily towards Jackrabbit). X-Envelope-From: brianboy@mac.com X-Envelope-To: Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2NKNJaZ027168 for ; Wed, 23 Mar 2005 12:23:19 -0800 Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id j2NKNI3d015203 for ; Wed, 23 Mar 2005 12:23:19 -0800 (PST) Received: from [17.255.128.88] ([17.255.128.88]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j2NKNHdT015154 for ; Wed, 23 Mar 2005 12:23:18 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 23 Mar 2005 12:23:17 -0800 From: BrianBoy To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Question on Discovery and CalDav Implementation 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 Mar 2005 20:23:21 -0000 I have a couple of questions 1) I am not sure this question was asked before anyways How will a caldav client discover the caldav server structure. Since caldav needs to operate on urls for eg. www.mydomain.com/caldav/users/brian/calendar Once the URL is known according to the draft it is possible to know it is a calendar resource by checking the property. Or does the client browse through the various collections to find a users calendar collection.? how would it even know that brian's calendar is in this url? how would it know if brian's url changed? 2) Does anybody out there have a caldav implementation on top of slide . I know there was a lot of discussion on this. I am wondering if a version exist? If it did where can I get it? Brian X-Envelope-From: TimHare@comcast.net Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j2G3BoaZ007168; Tue, 15 Mar 2005 19:11:50 -0800 Received: from thare.comcast.net (pcp03356962pcs.micske01.fl.comcast.net[68.84.26.220]) by comcast.net (rwcrmhc13) with SMTP id <200503160311440150048df6e>; Wed, 16 Mar 2005 03:11:45 +0000 Message-Id: <6.2.1.2.0.20050315220955.01d26ab8@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 15 Mar 2005 22:11:43 -0500 To: Lisa Dusseault , Helge Hess From: Tim Hare Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 In-Reply-To: <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> <57E15F5169F172D47195950F@ninevah.cyrusoft.com> <4f8343ca2d74bff678958d898435f604@opengroupware.org> <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST 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: Wed, 16 Mar 2005 03:11:53 -0000 I would imagine the problem of detecting a calendar which contains itself would be a real pain, too (Calendar A includes Calendar B which includes Calendar D, which includes Calendar A, for example). Besides, from the iCal-Basic / calsify standpoint, we're having enough trouble standardizing ONE level of calendar . At 02:16 PM 3/15/2005, Lisa Dusseault wrote: >On Mar 15, 2005, at 6:56 AM, Helge Hess wrote: > >>On Mar 7, 2005, at 1:53, Cyrus Daboo wrote: >>>>Whats the motivation behind this? Is there a particular reason why one >>>>calendar collection may not contain others? >>>> From IMAP experience I can tell you that having mailboxes that can contain >>>both messages and other 'sub' mailboxes is a real nightmare - from a >>>usability standpoint. I think it is well worth avoiding that mess if we can. >> >>Are there any technical reasons? > >Half-way between "technical reason" and "usability reason" is >ease-of-implementation reasons. It's significantly easier to implement a >client if the client knows that a calendar collection cannot contain >others. Not only does the code not have to handle both cases but the >design (GUI, workflow) can also can be simpler. > >> >> >>Section 4.2 >>I have another question on the 1:1 mapping between UIDs and collection >>relative URLs: >>---snip--- >>That is, each WebDAV resource MUST only contain iCalendar components with >>the same iCalendar UID property value, and all iCalendar components with >>the same iCalendar UID property value MUST be stored in the same WebDAV >>resource. >>---snap--- >> >>I wonder what is supposed to happen if a client writes an iCalendar >>vevent with a UID which already exists in the storage to a _new_ resource >>name (attempts to make a copy). >>Is the server supposed to ensure consistency? What kind of error should >>it return if it detects an attempt to create a duplicate uid? > >We certainly need to answer this question in the draft -- I think the >server should return an error but we haven't defined which one. > >> >>Would it makes sense to enforce that the relative URL equals the UID? >>This would ensure that the mapping is always correct. >That does follow the KISS principle, but I'm not sure that would work very >well in all cases. In a scheduling inbox we might see many resources with >the same UID, for example. I've been pushing for independence of URLs >from a gut feeling of it being a better decision in the long run, but I'm >not entirely satisfied with my own explanations of what's behind that gut >feeling. Part of the principle I followed there is that I would like to >keep the resource addressing independent of the data model and syntax >details of iCalendar. A possible benefit of independent URLs is that >clients could attempt some sort-of human-readable URL scheme if that >feature seemed valuable. And even if the benefits are a little vague, I >don't think this feature has much cost. > >Lisa > >_______________________________________________ >Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >See http://ietf.webdav.org/caldav/ for more CalDAV resources >http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Tim Hare Interested Bystander, Non-Inc. 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 j2FK9Daa019021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Mar 2005 12:09:15 -0800 Received: from plato.cyrusoft.com (plato.cyrusoft.com [63.163.82.23]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2FJtm6g003984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2005 14:55:48 -0500 Date: Tue, 15 Mar 2005 15:11:04 -0500 From: Cyrus Daboo To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Message-ID: <6BD4437A60A70B5DF6D9082F@plato.cyrusoft.com> In-Reply-To: <3d4c36d837097d6dcd733794eb9b71be@opengroupware.org> References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> <57E15F5169F172D47195950F@ninevah.cyrusoft.com> <4f8343ca2d74bff678958d898435f604@opengroupware.org> <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> <42373C35.6000906@Royer.com> <3d4c36d837097d6dcd733794eb9b71be@opengroupware.org> X-Mailer: Mulberry/4.0.0a7 (Win32) 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 Mar 2005 20:09:16 -0000 Hi Helge, --On Tuesday, March 15, 2005 21:00 +0100 Helge Hess wrote: >> All kinds of debates about how to compute busy time and >> what to show in the TOP calendar caused us to abandon the idea. > > Isn't the semantic on that well covered by the WebDAV depth header? Right now CalDAV does not forbid having regular collections (which could contain iCal components) inside of a calendar collection. So if calendar collections were also allowed inside, then there would be scoping issues wrt depth searches etc. Of course we could easily add a new option to the reports to handle that case, but that will just add more complexity. -- Cyrus Daboo 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 j2FK8IaZ018860 for ; Tue, 15 Mar 2005 12:08:19 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 829162E6BFD for ; Tue, 15 Mar 2005 21:07:28 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id 57CDD2E6BF9 for ; Tue, 15 Mar 2005 21:07:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> <57E15F5169F172D47195950F@ninevah.cyrusoft.com> <4f8343ca2d74bff678958d898435f604@opengroupware.org> <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Tue, 15 Mar 2005 21:08:12 +0100 To: CalDAV DevList 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 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 Mar 2005 20:08:26 -0000 On Mar 15, 2005, at 20:16, Lisa Dusseault wrote: > We certainly need to answer this question in the draft -- I think the > server should return an error but we haven't defined which one. OK. >> Would it makes sense to enforce that the relative URL equals the UID? >> This would ensure that the mapping is always correct. >> > That does follow the KISS principle, but I'm not sure that would work > very well in all cases. Ok. I just fear that using two identifiers for the same thing calls for trouble in implementations. Will be easy to confuse and get wrong, especially since the majority of calendaring clients will probably just reuse the uid as the URL anyway. > In a scheduling inbox we might see many resources with the same UID, > for example. A scheduling inbox would probably be a completely different kind of collection which doesn't follow the uid-constraint? Will scheduling be an addition to CalDAV or will that be in -06? > I've been pushing for independence of URLs from a gut feeling of it > being a better decision in the long run, but I'm not entirely > satisfied with my own explanations of what's behind that gut feeling. I have basically the same feeling because a generic client won't know about the UID, so you can't just drop a file into the collection and expect that to work. On the other side, it won't be able to deal with any dup-uid errors anyway. Mayb a redirect would help here (this time a real 302 which redirects to the uid location). > Part of the principle I followed there is that I would like to keep > the resource addressing independent of the data model and syntax > details of iCalendar. Reasonable. After all the UID is supposed to be unique across collections while the relative URL is only unique inside the collection. > A possible benefit of independent URLs is that clients could attempt > some sort-of human-readable URL scheme if that feature seemed > valuable. Ok, not sure whether it is really valuable, but I can imagine having a URL like /Calendar/MyMeeting[1] where MyMeeting[1] is the subject (+ uniquer). > And even if the benefits are a little vague, I don't think this > feature has much cost. Well, the cost is that you need additional error handling and tracking of two IDs in both, client and server. Anyway, just wanted to know. Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 j2FK0BaZ017291 for ; Tue, 15 Mar 2005 12:00:12 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 149252E6C0D for ; Tue, 15 Mar 2005 20:59:22 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-241-130.reverse.mdcc-fun.de [213.211.241.130]) by mail.mdlink.net (Postfix) with ESMTP id E7D912E6C4E for ; Tue, 15 Mar 2005 20:59:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <42373C35.6000906@Royer.com> References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> <57E15F5169F172D47195950F@ninevah.cyrusoft.com> <4f8343ca2d74bff678958d898435f604@opengroupware.org> <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> <42373C35.6000906@Royer.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3d4c36d837097d6dcd733794eb9b71be@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Tue, 15 Mar 2005 21:00:04 +0100 To: CalDAV DevList 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 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 Mar 2005 20:00:13 -0000 On Mar 15, 2005, at 20:49, Doug Royer wrote: > All kinds of debates about how to compute busy time and > what to show in the TOP calendar caused us to abandon the idea. Isn't the semantic on that well covered by the WebDAV depth header? But I see your point, I understand that this might raise discussions (personally I would have assumed that a folder is self contained and that the hierarchy has no special semantics). Consider my question answered. Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 j2FJnJaa014561 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Tue, 15 Mar 2005 11:49:20 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j2FJn9LM018827 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 15 Mar 2005 11:49:12 -0800 Message-ID: <42373C35.6000906@Royer.com> Date: Tue, 15 Mar 2005 12:49:09 -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: CalDAV DevList Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> <57E15F5169F172D47195950F@ninevah.cyrusoft.com> <4f8343ca2d74bff678958d898435f604@opengroupware.org> <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> In-Reply-To: <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090301080701050109080707" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.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 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: CalDAV DevList 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 Mar 2005 19:49:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090301080701050109080707 Content-Type: multipart/mixed; boundary="------------030301010204030301080902" This is a multi-part message in MIME format. --------------030301010204030301080902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > > On Mar 15, 2005, at 6:56 AM, Helge Hess wrote: > >> On Mar 7, 2005, at 1:53, Cyrus Daboo wrote: >> >>>> Whats the motivation behind this? Is there a particular reason why one >>>> calendar collection may not contain others? >>>> From IMAP experience I can tell you that having mailboxes that can >>>> contain >>> >>> both messages and other 'sub' mailboxes is a real nightmare - from a >>> usability standpoint. I think it is well worth avoiding that mess if >>> we can. >> >> >> Are there any technical reasons? > > Half-way between "technical reason" and "usability reason" is > ease-of-implementation reasons. It's significantly easier to implement > a client if the client knows that a calendar collection cannot contain > others. Not only does the code not have to handle both cases but the > design (GUI, workflow) can also can be simpler. And the fact that iCal does not allow it. This debate took place on the calsch mailing list and produced the RELATED-TO property for showing relationships between calendars and components. (parent, child, sibling). See the hierarchical calendars / roll-up debates. All kinds of debates about how to compute busy time and what to show in the TOP calendar caused us to abandon the idea. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030301010204030301080902 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 --------------030301010204030301080902-- --------------ms090301080701050109080707 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 9w0BCQUxDxcNMDUwMzE1MTk0OTA5WjAjBgkqhkiG9w0BCQQxFgQU3UuwTcNCLycWg26+pPg6 YXDqVRkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAIYxtk89w9wIeGYBEOBFvet+XmEmHManjbrht07SKopPFxUf0ri0o+jWT4cea4Eiz oJuIgbu6ePFI7Hrq/zcaPexVS09MIVKnDCs6k1ugVAvuIWDu04QWQaQefvYRKgMVt6QpwWct aAQdAw6C/8u+6XmEvUH5qp9Pwae4FTrzFbYwC8ZDFv2NvQ/xyvJGGE36gKfPqFa0CLbCVDV0 l2HVeW9sYRYwPw019lAvdoFVMmh5PeI2By9JR67CcqYJrymO9zu8DSPuvKxbuFKfLHt0rgqL dq1OCuABmlqDCElOyZ+aktxZCHZ4Sk0FhCTPv5gRYTA3iqqv0tuogNSFG8YCuQAAAAAAAA== --------------ms090301080701050109080707-- 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 j2FJGJaa007149 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Mar 2005 11:16:21 -0800 In-Reply-To: <4f8343ca2d74bff678958d898435f604@opengroupware.org> References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> <57E15F5169F172D47195950F@ninevah.cyrusoft.com> <4f8343ca2d74bff678958d898435f604@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2af347fb4caf8de414e33238a8ab6286@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Tue, 15 Mar 2005 11:16:12 -0800 To: Helge Hess X-Mailer: Apple Mail (2.619.2) 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 Mar 2005 19:16:22 -0000 On Mar 15, 2005, at 6:56 AM, Helge Hess wrote: > On Mar 7, 2005, at 1:53, Cyrus Daboo wrote: >>> Whats the motivation behind this? Is there a particular reason why >>> one >>> calendar collection may not contain others? >>> From IMAP experience I can tell you that having mailboxes that can >>> contain >> both messages and other 'sub' mailboxes is a real nightmare - from a >> usability standpoint. I think it is well worth avoiding that mess if >> we can. > > Are there any technical reasons? Half-way between "technical reason" and "usability reason" is ease-of-implementation reasons. It's significantly easier to implement a client if the client knows that a calendar collection cannot contain others. Not only does the code not have to handle both cases but the design (GUI, workflow) can also can be simpler. > > > Section 4.2 > I have another question on the 1:1 mapping between UIDs and collection > relative URLs: > ---snip--- > That is, each WebDAV resource MUST only contain iCalendar components > with the same iCalendar UID property value, and all iCalendar > components with the same iCalendar UID property value MUST be stored > in the same WebDAV resource. > ---snap--- > > I wonder what is supposed to happen if a client writes an iCalendar > vevent with a UID which already exists in the storage to a _new_ > resource name (attempts to make a copy). > Is the server supposed to ensure consistency? What kind of error > should it return if it detects an attempt to create a duplicate uid? We certainly need to answer this question in the draft -- I think the server should return an error but we haven't defined which one. > > Would it makes sense to enforce that the relative URL equals the UID? > This would ensure that the mapping is always correct. > That does follow the KISS principle, but I'm not sure that would work very well in all cases. In a scheduling inbox we might see many resources with the same UID, for example. I've been pushing for independence of URLs from a gut feeling of it being a better decision in the long run, but I'm not entirely satisfied with my own explanations of what's behind that gut feeling. Part of the principle I followed there is that I would like to keep the resource addressing independent of the data model and syntax details of iCalendar. A possible benefit of independent URLs is that clients could attempt some sort-of human-readable URL scheme if that feature seemed valuable. And even if the benefits are a little vague, I don't think this feature has much cost. Lisa 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 j2FEuDaZ017223 for ; Tue, 15 Mar 2005 06:56:14 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 412CB2E6823 for ; Tue, 15 Mar 2005 15:55:21 +0100 (CET) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id AB94C2E67EE for ; Tue, 15 Mar 2005 15:55:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <57E15F5169F172D47195950F@ninevah.cyrusoft.com> References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> <57E15F5169F172D47195950F@ninevah.cyrusoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4f8343ca2d74bff678958d898435f604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Tue, 15 Mar 2005 15:56:05 +0100 To: CalDAV DevList 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 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 Mar 2005 14:56:15 -0000 On Mar 7, 2005, at 1:53, Cyrus Daboo wrote: >> Whats the motivation behind this? Is there a particular reason why one >> calendar collection may not contain others? >> From IMAP experience I can tell you that having mailboxes that can >> contain > both messages and other 'sub' mailboxes is a real nightmare - from a > usability standpoint. I think it is well worth avoiding that mess if > we can. Are there any technical reasons? Section 4.2 I have another question on the 1:1 mapping between UIDs and collection relative URLs: ---snip--- That is, each WebDAV resource MUST only contain iCalendar components with the same iCalendar UID property value, and all iCalendar components with the same iCalendar UID property value MUST be stored in the same WebDAV resource. ---snap--- I wonder what is supposed to happen if a client writes an iCalendar vevent with a UID which already exists in the storage to a _new_ resource name (attempts to make a copy). Is the server supposed to ensure consistency? What kind of error should it return if it detects an attempt to create a duplicate uid? Would it makes sense to enforce that the relative URL equals the UID? This would ensure that the mapping is always correct. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: jeffrey@skyhouseconsulting.com X-Envelope-To: Received: from mail.skyhouseconsulting.com (skyhouseconsulting.com [69.55.227.180]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j283H1aa024772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Mar 2005 19:17:01 -0800 Received: from [192.168.1.99] (unknown [216.146.255.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhouseconsulting.com (Postfix) with ESMTP id 3A7C9EAE1AA for ; Mon, 7 Mar 2005 21:17:01 -0600 (CST) Message-ID: <422D1931.2010400@skyhouseconsulting.com> Date: Mon, 07 Mar 2005 21:17:05 -0600 From: Jeffrey Harris User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Fwd: CalDAV article online References: <3164f39fdeb82f4e2e9ce097cc2b54d6@osafoundation.org> In-Reply-To: <3164f39fdeb82f4e2e9ce097cc2b54d6@osafoundation.org> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 08 Mar 2005 03:17:03 -0000 Hi Folks, The URL for the CalDAV article at IEEE Distributed Systems Online required cutting and pasting for me, I thought I'd save everyone else the effort, here's a tinyurl for it: Sincerely, Jeffrey Harris X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [130.129.67.86] (wired-130-129-67-86.ietf62.ietf.org [130.129.67.86]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j282D2aa011111 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 7 Mar 2005 18:13:03 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) To: CalDAV DevList Message-Id: <3164f39fdeb82f4e2e9ce097cc2b54d6@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-1-944276136 From: Lisa Dusseault Date: Mon, 7 Mar 2005 18:12:58 -0800 X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Fwd: CalDAV article online 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, 08 Mar 2005 02:13:04 -0000 --Apple-Mail-1-944276136 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI Begin forwarded message: > From: "Jim Whitehead" > Date: March 7, 2005 1:32:37 PM PST > To: "'Lisa Dusseault'" > Subject: CalDAV article online > Reply-To: > > Lisa, > > It appears the CalDAV article is freely available online at: > > http://dsonline.computer.org/portal/site/dsonline/ > menuitem.9ed3d9924aeb0dcd8 > 2ccc6716bbe36ec/index.jsp? > menuitem.9ed3d9924aeb0dcd > 82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/ > 0504&file=w2sta.x > ml&xsl=article.xsl&> > &pName=dso_level1&path=dsonline/0504&file=w2sta.xml&xsl=article.xsl& > > (horrible URL, but it works) > > - Jim > --Apple-Mail-1-944276136 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII FYI Begin forwarded message: 0000,0000,0000From: "Jim Whitehead" < 0000,0000,0000Date: March 7, 2005 1:32:37 PM PST 0000,0000,0000To: "'Lisa Dusseault'" < 0000,0000,0000Subject: CalDAV article online 0000,0000,0000Reply-To: < Lisa, It appears the CalDAV article is freely available online at: http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd8 2ccc6716bbe36ec/index.jsp? < &pName=dso_level1&path=dsonline/0504&file=w2sta.xml&xsl=article.xsl& (horrible URL, but it works) - Jim --Apple-Mail-1-944276136-- 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 j270v4aa015864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Mar 2005 16:57:05 -0800 Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j270ix6g004773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 19:45:01 -0500 Date: Sun, 06 Mar 2005 19:57:04 -0500 From: Cyrus Daboo To: Helge Hess , ietf-caldav Subject: Re: [Ietf-caldav] GroupDAV / CalDAV relationship Message-ID: <5E44791EAE26C30D829340FC@ninevah.cyrusoft.com> In-Reply-To: <4b6dc49bbe454b85941da702019fbbef@opengroupware.org> References: <4b6dc49bbe454b85941da702019fbbef@opengroupware.org> X-Mailer: Mulberry/3.2.0a1 (Linux/PPC) 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: groupdav@opengroupware.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, 07 Mar 2005 00:57:06 -0000 Hi Helge, --On Sunday, March 06, 2005 09:51:25 PM +0100 Helge Hess wrote: > Hopefully the two efforts will be able to work together in a useful way. > At least I'm going to work on that - why?, because at least for OGo the > efforts are complementary. GroupDAV to get basic native client > connectivity, CalDAV to have a well specified protocol to access advanced > calendaring features. I kind of see the two as similar to the POP and IMAP relationship. The key difference between those two is that the server does a lot more work in IMAP on behalf of the client (e.g. server side searching, sorting, partial downloads etc). In a similar manner CalDAV has server-side 'smart' features for doing partial retrieval at different levels - plus it will also handle the scheduling part itself. -- 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 j270rIaa015675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Mar 2005 16:53:19 -0800 Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j270fA6g004628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 19:41:14 -0500 Date: Sun, 06 Mar 2005 19:53:15 -0500 From: Cyrus Daboo To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Message-ID: <57E15F5169F172D47195950F@ninevah.cyrusoft.com> In-Reply-To: <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> References: <422B5D86.9060409@gmx.de> <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> X-Mailer: Mulberry/3.2.0a1 (Linux/PPC) 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: Mon, 07 Mar 2005 00:53:20 -0000 Hi Helge, --On Monday, March 07, 2005 12:54:02 AM +0100 Helge Hess wrote: > I just wonder about this: > http://greenbytes.de/tech/webdav/draft-dusseault-caldav > -05.html#calendar-collection > > ---snip--- > Calendar collections MUST NOT contain other calendar collections. > ---snap--- > > Whats the motivation behind this? Is there a particular reason why one > calendar collection may not contain others? >From IMAP experience I can tell you that having mailboxes that can contain both messages and other 'sub' mailboxes is a real nightmare - from a usability standpoint. I think it is well worth avoiding that mess if we can. -- Cyrus Daboo 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 j26Ns8aZ011445 for ; Sun, 6 Mar 2005 15:54:09 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 789BC2E2DFD for ; Mon, 7 Mar 2005 00:53:32 +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 56C7E2E2DF6 for ; Mon, 7 Mar 2005 00:53:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <422B5D86.9060409@gmx.de> References: <422B5D86.9060409@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3d051ab7c1af761e8e1d80c538f91bfc@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Mon, 7 Mar 2005 00:54:02 +0100 To: CalDAV DevList 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 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: Sun, 06 Mar 2005 23:54:10 -0000 Hi, I just wonder about this: http://greenbytes.de/tech/webdav/draft-dusseault-caldav -05.html#calendar-collection ---snip--- Calendar collections MUST NOT contain other calendar collections. ---snap--- Whats the motivation behind this? Is there a particular reason why one calendar collection may not contain others? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 j26KuMaZ001955 for ; Sun, 6 Mar 2005 12:56:23 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 235712E2CE6 for ; Sun, 6 Mar 2005 21:55:54 +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 01A622E2CE5 for ; Sun, 6 Mar 2005 21:55:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <15E3D38DD5378F06A173F0A6@ninevah.cyrusoft.com> References: <422B5D86.9060409@gmx.de> <343bfb41e0d14b38c845978b3710a566@opengroupware.org> <422B629E.7010807@gmx.de> <3a5d87b842358a29b0f537d3cf227881@opengroupware.org> <422B669E.4080202@gmx.de> <15E3D38DD5378F06A173F0A6@ninevah.cyrusoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9f4e41e5be14acfe79168a8c88cb8f60@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Sun, 6 Mar 2005 21:56:16 +0100 To: CalDAV DevList 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 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: Sun, 06 Mar 2005 20:56:23 -0000 On 6. Mrz 2005, at 21:41 Uhr, Cyrus Daboo wrote: > OK - just to put this one to bed, at least in regards to CalDAV - it > is our (the authors') intention to remove this 'redirect on PUT' > behaviour from the CalDAV draft. Instead, if a server has this type of > behaviour, then it can use whatever generic http solution is finally > settled on (ADDMEMBER, POST, PUT + status code etc). Hm, yes, I think this makes perfect sense. After all a server which has this type of behaviour would be HTTP compliant in any case, the "location" is just an optimization to reduce roundtrips and "likeliness" of a conflict. There is no difference whether the server renames the item concurrently or some other client/user, so the client cannot expect a permanent URL in any case. If the next PUT with an etag fails, it will probably need to find the "new" URL using an iCal UID search (that there is a 1:1 relationship between URL and UID is already in the -05 draft I think). I suppose this should be outlined in the draft? Or if the above is not allowed/intended, it should state that once an iCal resource with a given UID was bound to a certain URL that this may not change (also that a MOVE would be forbidden). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 j26KpWaZ001660 for ; Sun, 6 Mar 2005 12:51:32 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 23B102E2CDA; Sun, 6 Mar 2005 21:51:03 +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 83C032E2CCD; Sun, 6 Mar 2005 21:51:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4b6dc49bbe454b85941da702019fbbef@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Date: Sun, 6 Mar 2005 21:51:25 +0100 To: ietf-caldav 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 Cc: groupdav@opengroupware.org Subject: [Ietf-caldav] GroupDAV / CalDAV relationship 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: Sun, 06 Mar 2005 20:51:34 -0000 Hi, last week there was an inappropriate post about GroupDAV on Slashdot as most of you probably have noticed. Being one of the primary creators of the draft I think I need to clear up some of the confusion that resulted from the post (again: this was _not_ a post by the GroupDAV group, it was a posting by one individual). I hope that this longish mail manages to explain what our effort is about. GroupDAV is something which was invented for a very specific need, less as a general protocol which is supposed to get submitted to the IETF like CalDAV. We definitely do not intend to compete with CalDAV as a standard - this is out of question due to our specific focus. Our goal is to fix the issue that there are some excellent OpenSource groupware clients and loads of OpenSource groupware servers, yet they do not connect at all. Its kinda weird if the only "official" option to connect a server like OGo to Evolution in _2005_ is to fake being a proprietary server, be that Exchange (like OGo did) or Groupwise. In our opinion this is/was mostly because a single OpenSource server project does not have the "critical mass" to be interesting to the client vendors. So whats different. Our focus is to connect _just_ the three popular OpenSource groupware clients - Kontact, Evolution and Sunbird (in that order) with "arbitary" OpenSource groupware servers. "Arbitary", because a lot of the servers often have a quite specific focus, eg we want to cover a server like Bugzilla in a useful way. This puts us in an environment like this: 1) we only need to specify offline synchronisation to the local client, no other reports like range queries are needed (except maybe for folder discovery) 2) we can assume perfect iCalendar/vCard compatibility in the local clients, since all of them are based fully on iCalendar/vCard 3) we need to deal with less than perfect iCal/vCard compatibility in the servers 4) we MUST be trivial to implement in existing servers, few OpenSource people will bother if it requires a week to implement the protocol, they usually do the work in their sparetime 5) we need to support a bit more functionality, for groupware we at least want to share contact data using HTTP 6) the far majority of OpenSource servers are based on HTTP (whether PHP, Perl or some other technology) 7) few servers will have full WebDAV compliance, if WebDAV support at all The major consequences are that a) The client must expect that it may not be able to save all iCalendar/vCard information in the server or that the servers deal with it in a different way. Eg recurrences are one thing which are very often handled different to iCal. b) Both, client and server implementations are very simple. Basically they just need to support HTTP PUT/GET/DELETE with etags plus one fixed PROPFIND query to detect changes. Yes, we know that the results of that is not 100% perfect. But we consider a panel which tells the user that something could not be written with some info on how to workaround that better than having no client support at all. Notably a GroupDAV server doesn't even need to support WebDAV. It just needs to support one predefined PROPFIND on two specific properties for cache synchronisation. No arbitary property queries, no arbitary iCal content reports. What we have accomplished so far. Draft: we still only have the first revision of the draft plus a collection of issues which need to get incorporated. The document should be treated as such, not like a fully reviewed specification. Clients: The Kontact support for GroupDAV was the effort which actually resulted in the draft. The implementation required just two days to get reasonable interoperability plus some sparetime work to fix some open issues. Fortunately OGo as a project is sufficiently popular today so that some real world customers actually sponsored the development of a GroupDAV connector for Evolution as well as for Sunbird. The Evolution one is working well, the Sunbird one is work in progress. Summary: we have almost accomplished our goals at the client side. Of course the client connectors need to mature just like the draft. Servers: currently there are just three servers implementing GroupDAV, two of them based on the OGo frameworks. We hope that this will change once the draft and clients stabilize. Getting support for all the major OpenSource clients with very little work should be quite interesting for servers. How does all that matter to CalDAV? IMHO any work being done on GroupDAV connectors is an excellent basis for developing support for full featured CalDAV implementations, that is, it pushes CalDAV adoption. Actually our goal is to keep GroupDAV as compatible with CalDAV as possible - ideally you would be able to use a GroupDAV client connector with any full blown CalDAV server immediatly. Is GroupDAV the "CalDAV Level 0" which was asked for in the past? Maybe, I don't know. At least one difference is that GroupDAV also provides vCard synchronisation which is important in our context. I would be happy to discuss that matter, but I fear the GroupDAV approach might be too "pragmatic" as an IETF standard. Eg requiring full WebDAV would be a no-go. Hopefully the two efforts will be able to work together in a useful way. At least I'm going to work on that - why?, because at least for OGo the efforts are complementary. GroupDAV to get basic native client connectivity, CalDAV to have a well specified protocol to access advanced calendaring features. Feel free to ask me any questions you have. best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 j26Kfuaa001072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Mar 2005 12:41:57 -0800 Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j26KTe6g032440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 15:29:42 -0500 Date: Sun, 06 Mar 2005 15:41:43 -0500 From: Cyrus Daboo To: Julian Reschke , Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Message-ID: <15E3D38DD5378F06A173F0A6@ninevah.cyrusoft.com> In-Reply-To: <422B669E.4080202@gmx.de> References: <422B5D86.9060409@gmx.de> <343bfb41e0d14b38c845978b3710a566@opengroupware.org> <422B629E.7010807@gmx.de> <3a5d87b842358a29b0f537d3cf227881@opengroupware.org> <422B669E.4080202@gmx.de> X-Mailer: Mulberry/3.2.0a1 (Linux/PPC) 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: 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: Sun, 06 Mar 2005 20:41:59 -0000 Hi Julian, --On Sunday, March 06, 2005 09:22:54 PM +0100 Julian Reschke wrote: > Helge Hess wrote: >> On 6. Mrz 2005, at 21:05 Uhr, Julian Reschke wrote: >> >>> Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986) >>> that this is a protocol violation; see >>> >> 0066.html>). >> >> >> I don't find a simple >> ---snip--- >> That is not allowed in HTTP. >> ---snap--- >> particulary convincing (the rest of the text is about using POST). > > ...in which case you should follow up to Roy's posting over at the IETF > HTTP WG. > > I think I've done my part in documenting the issue and proposing > alternatives :-) > >> ... OK - just to put this one to bed, at least in regards to CalDAV - it is our (the authors') intention to remove this 'redirect on PUT' behaviour from the CalDAV draft. Instead, if a server has this type of behaviour, then it can use whatever generic http solution is finally settled on (ADDMEMBER, POST, PUT + status code etc). -- 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 j26KNJaZ032705 for ; Sun, 6 Mar 2005 12:23:20 -0800 Received: (qmail invoked by alias); 06 Mar 2005 20:23:13 -0000 Received: from pD95351F5.dip.t-dialin.net (EHLO [192.168.0.4]) (217.83.81.245) by mail.gmx.net (mp018) with SMTP; 06 Mar 2005 21:23:13 +0100 X-Authenticated: #1915285 Message-ID: <422B669E.4080202@gmx.de> Date: Sun, 06 Mar 2005 21:22:54 +0100 From: Julian Reschke 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] Comments on draft-dusseault-caldav-05 References: <422B5D86.9060409@gmx.de> <343bfb41e0d14b38c845978b3710a566@opengroupware.org> <422B629E.7010807@gmx.de> <3a5d87b842358a29b0f537d3cf227881@opengroupware.org> In-Reply-To: <3a5d87b842358a29b0f537d3cf227881@opengroupware.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: 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: Sun, 06 Mar 2005 20:23:22 -0000 Helge Hess wrote: > On 6. Mrz 2005, at 21:05 Uhr, Julian Reschke wrote: > >> Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986) >> that this is a protocol violation; see >> > 0066.html>). > > > I don't find a simple > ---snip--- > That is not allowed in HTTP. > ---snap--- > particulary convincing (the rest of the text is about using POST). ...in which case you should follow up to Roy's posting over at the IETF HTTP WG. I think I've done my part in documenting the issue and proposing alternatives :-) > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 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 j26KHwaZ032364 for ; Sun, 6 Mar 2005 12:17:58 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 4510F2E2CA0 for ; Sun, 6 Mar 2005 21:17:29 +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 CAF902E2C7A for ; Sun, 6 Mar 2005 21:17:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <422B629E.7010807@gmx.de> References: <422B5D86.9060409@gmx.de> <343bfb41e0d14b38c845978b3710a566@opengroupware.org> <422B629E.7010807@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3a5d87b842358a29b0f537d3cf227881@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Sun, 6 Mar 2005 21:17:51 +0100 To: CalDAV DevList 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 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: Sun, 06 Mar 2005 20:18:00 -0000 On 6. Mrz 2005, at 21:05 Uhr, Julian Reschke wrote: > Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986) > that this is a protocol violation; see > 0066.html>). I don't find a simple ---snip--- That is not allowed in HTTP. ---snap--- particulary convincing (the rest of the text is about using POST). If thats not allowed in HTTP the HTTP spec probably should be reviewed to state that fact explicitly. I think that such a review is required is fairly obvious since a lot of people (including me) interpret the text in a different way. Personally I'm still very open to get convinced that PUT+location is wrong. But some suitable arguments are required for that (please do not repost the ones you already brough up ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 j26K6IaZ031633 for ; Sun, 6 Mar 2005 12:06:19 -0800 Received: (qmail invoked by alias); 06 Mar 2005 20:06:12 -0000 Received: from pD95351F5.dip.t-dialin.net (EHLO [192.168.0.4]) (217.83.81.245) by mail.gmx.net (mp011) with SMTP; 06 Mar 2005 21:06:12 +0100 X-Authenticated: #1915285 Message-ID: <422B629E.7010807@gmx.de> Date: Sun, 06 Mar 2005 21:05:50 +0100 From: Julian Reschke 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] Comments on draft-dusseault-caldav-05 References: <422B5D86.9060409@gmx.de> <343bfb41e0d14b38c845978b3710a566@opengroupware.org> In-Reply-To: <343bfb41e0d14b38c845978b3710a566@opengroupware.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: 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: Sun, 06 Mar 2005 20:06:20 -0000 Helge Hess wrote: > On 6. Mrz 2005, at 20:44 Uhr, Julian Reschke wrote: > >> 04-C06, Section 6.2 >> >> > -04.html#rfc.section.6.2> >> >> 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. > > > That the opinions are mixed on the PUT+location is nothing new ;-) > > Yet the response still has a problem because it uses location and the > etag. I think this is invalid in any case, if the server returns a new > location, the client must fetch the etag of the resource from the new > location. That's correct. Anyway, we heard from Roy Fielding (author of RFC2616 and RFC3986) that this is a protocol violation; see ). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 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 j26JxMaZ031035 for ; Sun, 6 Mar 2005 11:59:22 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D2E4A2E2975 for ; Sun, 6 Mar 2005 20:58:52 +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 ACAAB2E2592 for ; Sun, 6 Mar 2005 20:58:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <422B5D86.9060409@gmx.de> References: <422B5D86.9060409@gmx.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <343bfb41e0d14b38c845978b3710a566@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Comments on draft-dusseault-caldav-05 Date: Sun, 6 Mar 2005 20:59:15 +0100 To: CalDAV DevList 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 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: Sun, 06 Mar 2005 19:59:25 -0000 On 6. Mrz 2005, at 20:44 Uhr, Julian Reschke wrote: > 04-C06, Section 6.2 > > -04.html#rfc.section.6.2> > > 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. That the opinions are mixed on the PUT+location is nothing new ;-) Yet the response still has a problem because it uses location and the etag. I think this is invalid in any case, if the server returns a new location, the client must fetch the etag of the resource from the new location. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 j26JiYaZ030034 for ; Sun, 6 Mar 2005 11:44:35 -0800 Received: (qmail invoked by alias); 06 Mar 2005 19:44:27 -0000 Received: from pD95351F5.dip.t-dialin.net (EHLO [192.168.0.4]) (217.83.81.245) by mail.gmx.net (mp013) with SMTP; 06 Mar 2005 20:44:27 +0100 X-Authenticated: #1915285 Message-ID: <422B5D86.9060409@gmx.de> Date: Sun, 06 Mar 2005 20:44:06 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList 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 Subject: [Ietf-caldav] Comments on draft-dusseault-caldav-05 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: Sun, 06 Mar 2005 19:44:38 -0000 Hi, below are some comments on the current draft, mainly from a WebDAV (as opposed to Calendaring) perspective. Best regards, Julian 05-C01, Section 2 It doesn't make sense to state that a server MAY support additional WebDAV features. A server is free to support any additional methods/properties/REPORTs it likes. 05-C02, Section 4.1, Calendar Collection "...A calendar collection MUST have ..., and a DAV:resourcetype property..." *Any* WebDAV resource MUST have a DAV:resourcetype property. Remove that part of the sentence. 05-C03, Section 4.1, Calendar Collection It would be nice if there would be a single place that would state what additional properties a DAV collection must have to be a calendar collection. As far as I can tell, it's the special resource type, and the restriction that calendar collections can't be nested. Is there anything else? 05-C04, Section 5.1, MKCALENDAR "In the event that the DAV:displayname property is empty, the client MAY use the last part of the calendar-collection URI as the name." That should read: "In the event the DAV:displayname property isn't present, ..." 05-C05, Section 5.1, MKCALENDAR "(CALDAV:insufficient-privilege): The DAV:bind privilege MUST be granted to the current authenticated user." This conflicts with DAV:needs-privileges; defined in . 05-C06, Section 5.1.1, MKCALENDAR status codes It's dangerous to attempt lists like these. Either drop it or make sure these are only examples. Clients MUST handle status codes as defined per RFC2616, in particular those not mentioned here. 05-C07, Section 5.2.1, Capability discovery Is there anything a client can detect using the "calendar-access" DAV compliance class that it couldn't find out based on live properties, resource types and supported methods? If "no", please consider removing this. 05-C08, Section 5.2, OPTIONS request bodies I'm aware that this re-uses marshalling from RFC3253, but exactly this feature is deprecated (see and issues 5.5_OPTIONS_BODY and 5.5_USE_PROPERTIES on the DeltaV Issues List (). Just make those live properties instead. 05-C09, Section 5.2.3, CALDAV:current-user-calendar-collection-set "A CALDAV:current-user-calendar-collection-set element MAY be included in the request body to identify the calendar collections owned by the current authenticated user." I think the concept of "the" authenticated user may be a bit vague. An authenticated principal may "match" more than a single principal, for instance a group. Would URIs or group calendars be included here? 05-C10, Section 6.1, CALDAV:calendar-description The definition of this property seems to be exactly identical to DAV:displayname. What's the difference? 05-C11, Section 8, Calendaring Reports "Clients SHOULD request the DAV:getetag property whenever executing reports that return calendar data, to ensure that any local cache used for synchronization is kept up to date with the latest changes on the server" Just requesting them will not have that effect :-). Later in the document this is explained with more detail; so maybe a dorward reference would be useful. 05-C12, CALDAV:calendar-data element I suspect that complexity in the spec could be reduced by simply exposing what's called CALDAV:calendar-data as a live property. 04-C06, Section 6.2 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. 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 j24N0raZ010534 for ; Fri, 4 Mar 2005 15:00:53 -0800 Received: from [10.2.1.144] ([10.2.1.144]) by exchange01.corp.dccusa.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Mar 2005 17:02:07 -0600 Message-ID: <4228E8A6.9020503@progbits.com> Date: Fri, 04 Mar 2005 17:00:54 -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@osafoundation.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2005 23:02:07.0233 (UTC) FILETIME=[303A8F10:01C5210E] X-Spam-Score: 0.47 () TO_ADDRESS_EQ_REAL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-caldav] Novel Nula project - Article 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, 04 Mar 2005 23:00:57 -0000 Figured everyone here may be interested in this article. It talks about CalDav. http://www.linuxworld.com.au/index.php/id;483367312;fp;2;fpid;3 Have fun... -- Scott Carr OpenOffice.org Documentation Co-Lead http://documentation.openoffice.org