X-Envelope-From: elias@cse.ucsc.edu X-Envelope-To: Received: from gate.arc.nasa.gov (gate.arc.nasa.gov [128.102.102.51]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7RGnxpo006730 for ; Fri, 27 Aug 2004 09:49:59 -0700 Received: from [143.232.67.216] (esinderson.arc.nasa.gov [143.232.67.216]) by gate.arc.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id i7RGnwm23462 for ; Fri, 27 Aug 2004 09:49:58 -0700 (PDT) Message-ID: <412F6636.9070303@cse.ucsc.edu> Date: Fri, 27 Aug 2004 09:49:58 -0700 From: Elias Sinderson User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Creating a calendar References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> In-Reply-To: <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 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: Fri, 27 Aug 2004 16:49:59 -0000 Lisa Dusseault wrote: > I also like the idea of looking at the principal resource to find out > more information like where the user's calendar is homed, where the > user's other file sharing space can be found, etc. CalDAV would only > have to define a property on the principal resource for this to work [...] +1 - simple and elegant. Cyrus Daboo wrote: > Lisa Dusseault wrote: > >> When a user logs in, the ACL standard defines a REPORT to ask "who am >> I". >> With that report the client gets the mapping from the user's login ID to >> a principal URL. > > But that does not help locating calendars for resources that are not > associated with a principal e.g. public calendars, calendars for > meeting rooms etc One could argue that you could use DASL to find > those things, but I think having a NAMESPACE report would be better. Presumably these resources could also be located via other means (links from a corporate intranet web site, group homepage, etc.). As long as a client provides a way for a user to enter in the location of a calendar the issue is somewhat moot. I do support the notion of automatic / programmatic location of calendar resources, however I don't believe that it necessarily entails the creation of a new report type. You are completely correct in that DASL is general enough to support this use case - can you explain why you believe that the report approach is somehow better? IMHO, using DASL for calendar resource discovery makes perfect sense and wouldn't put an inordinate amount of load on a server, considering that the discovery process would only happen infrequently at worst and only a few times per user / client at best (on a given server). Cheers, Elias 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 i7R3DLpo031027 for ; Thu, 26 Aug 2004 20:13:22 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0A2A7282434 for ; Fri, 27 Aug 2004 05:13:14 +0200 (CEST) Received: from [192.168.102.125] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 2DA022823F6 for ; Fri, 27 Aug 2004 05:13:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <6.1.1.1.0.20040826223414.027b5d50@mail.comcast.net> References: <412E429A.4060504@oracle.com> <10E306F2C4CA4D160E3F410E@plato.cyrusoft.com> <412E9B89.6080709@oracle.com> <6.1.1.1.0.20040826223414.027b5d50@mail.comcast.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <08647C3C-F7D7-11D8-AE89-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating a calendar Date: Fri, 27 Aug 2004 05:13:13 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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, 27 Aug 2004 03:13:22 -0000 On Aug 27, 2004, at 4:37, TimHare@comcast.net wrote: >> In regard to "one personal calendar per user" - is that one per user, >> per calendar store? For example, I would have a calendar at home, >> possibly one for work with the home business of my wife, and also a >> personal calendar where I work. When scheduling time for myself, it >> would be nice for my calendaring client to do a union operation on >> the free/busy time of all of those calendars, so that all of my busy >> time is discovered before the scheduling happens. I think this is covered by this section: ---snip--- 4.3 Event Collection Each Calendar MUST have a collection containing events. All resources within this event collection (even within its sub-collections) are considered part of the calendar, so substructure can be used to organize events into smaller collections without affecting the overall content of the calendar. Clients MUST be prepared to identify and navigate multiple event collections within a Calendar. ---snap--- So the "event collection" is more like a traditional calendar and the CalDAV calendar is the WebDAV collection which manages your calendar. Eg if you imagine Apple iCalendar or Mozilla Calendar, it allows you to have several of those colorful "calendars". Those would be event collections in CalDAV and the store of the application itself would be a single calendar. Because they are in a single CalDAV "calendar", all the reports would treat the event collections as a single database. [correct me if I'm wrong ;-)] What I haven't understood yet is the point of 4.1, Calendar Container. It would be great if someone could explain. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 i7R2kFpo027318 for ; Thu, 26 Aug 2004 19:46:15 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc11) with SMTP id <2004082702460701300r8cnje> (Authid: TimHare); Fri, 27 Aug 2004 02:46:08 +0000 Message-Id: <6.1.1.1.0.20040826223414.027b5d50@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 26 Aug 2004 22:37:15 -0400 To: ietf-caldav@osafoundation.org From: TimHare@comcast.net Subject: Re: [Ietf-caldav] Creating a calendar In-Reply-To: <412E9B89.6080709@oracle.com> References: <412E429A.4060504@oracle.com> <10E306F2C4CA4D160E3F410E@plato.cyrusoft.com> <412E9B89.6080709@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 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, 27 Aug 2004 02:46:16 -0000 >In regard to "one personal calendar per user" - is that one per user, per >calendar store? For example, I would have a calendar at home, possibly one >for work with the home business of my wife, and also a personal calendar >where I work. When scheduling time for myself, it would be nice for my >calendaring client to do a union operation on the free/busy time of all of >those calendars, so that all of my busy time is discovered before the >scheduling happens. Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7R2PGpp023624 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 19:25:17 -0700 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7R2PAU7017047 for ; Thu, 26 Aug 2004 19:25:10 -0700 Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7R2PAIl014322 for ; Thu, 26 Aug 2004 20:25:10 -0600 Received: from oracle.com (dhcp-amer-vpn-rmdc-gw2-west-141-144-112-99.vpn.oracle.com [141.144.112.99]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7R2P9rh014301 for ; Thu, 26 Aug 2004 20:25:09 -0600 Message-ID: <412E9B89.6080709@oracle.com> Date: Thu, 26 Aug 2004 22:25:13 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Creating a calendar References: <412E429A.4060504@oracle.com> <10E306F2C4CA4D160E3F410E@plato.cyrusoft.com> In-Reply-To: <10E306F2C4CA4D160E3F410E@plato.cyrusoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 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, 27 Aug 2004 02:25:17 -0000 Cyrus Daboo wrote: > Hi Bernard, > > --On Thursday, August 26, 2004 4:05 PM -0400 Bernard Desruisseaux > wrote: > >> I see calendar creation more as a provisioning issue, and >> thus probably outside the scope of CalDAV. > > > I disagree - I expect users to be able to create, organize, delete etc a > hierarchy of calendars and that must be possible via the caldav client. Hi Cyrus, In my opinion, a user should only have one personal "Calendar", in which he could create and delete as many "Folders" as please him for filing purposes. When a user is provisioned with a calendar account, at least one new collection on which this user will have write privileges will need to be created for him. This collection would be his "Calendar" root point (e.g., http://example.com/caldav/calendars/bernard/). When we will look more closely at scheduling operation we might come up with mandatory/default Folders for incoming iTIP messages (e.g., Inbox) and perhaps outgoing iTIP messages (e.g., Outbox). The difference between "Calendars" and "Calendar Folders" might become important for scheduling when we will decide if we use HTTP URL for calendar addresses or MAILTO URI. BTW, CAP is using CAP URI, iRIP was proposing to use IRIP URI, and iSIP was proposing to use SIP URI. > >> A user could find the location of his calendars by looking >> at the "calendars" property (see section 11.2) of his own >> principal resource (e.g., http://example.com/users/bernard) >> assuming the user knows the URL of his own principal resource. >> I don't actually know how he would though. > > > Actually one thing I would like to propose is the equivalent of the IMAP > NAMESPACE extension. Specifically a REPORT that would list key URLs for > the different caldav store paths a user's client should provision itself > with. That would include a URL to the users personal calendars, one for > shared (other users) calendars, and one for public calendars. In > addition a URL to the principals collection would also be handy to make > working with ACLs easy. I agree that CalDAV should specify a way to address this. > > In the process of our work I wrote something up on this and have > attached a rough outline of that as a second text part to this message. > I would like to know if this is something we should consider for caldav. I wonder if we really need a report to address this issue though. Perhaps, all the namespaces, except "Personal", could be specified as properties of the caldav-root collection. Note that ACL-Users and ACL-Groups would be better off in a webdav-root collection as they aren't specific to CalDAV. Your proposal assumes that one knows the caldav-root collection. The user may as well look at the properties of this collection. As for the "Personal" namespace, I'm looking forward to see what Lisa had in mind to figure out "Who am I?". If we can avoid a REPORT I think we should, else let's do it. Cheers, Bernard X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet03.oracle.com (agminet03.oracle.com [141.146.126.230]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7R0uHpp002410 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 17:56:18 -0700 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7R0u8fr019642 for ; Thu, 26 Aug 2004 17:56:10 -0700 Received: from rgmgw3.us.oracle.com (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7R0u7l0004785 for ; Thu, 26 Aug 2004 18:56:07 -0600 Received: from oracle.com (dhcp-amer-vpn-rmdc-gw2-west-141-144-112-99.vpn.oracle.com [141.144.112.99]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7R0u5n5004731 for ; Thu, 26 Aug 2004 18:56:07 -0600 Message-ID: <412E86A8.9040907@oracle.com> Date: Thu, 26 Aug 2004 20:56:08 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Creating a calendar References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> In-Reply-To: <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 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, 27 Aug 2004 00:56:19 -0000 Lisa, Actually, I did look at WebDAV ACL today and I couldn't find any report that would allow me to ask "Who am I?". Which of the 4 WebDAV REPORTs do you have in mind exactly? Cheers, Bernard Lisa Dusseault wrote: > Could be provisioning, yes. For example, a CalDAV server might create > the collections only when the user first logs in to an authorized > account (LDAP or other). Or there might be a Web page for requesting a > calendar repository. I think this is not a requirement for CalDAV to > cover but I may be wrong about the use cases. > > I also like the idea of looking at the principal resource to find out > more information like where the user's calendar is homed, where the > user's other file sharing space can be found, etc. CalDAV would only > have to define a property on the principal resource for this to work -- > the principal resources are locatable through special ACL REPORTs. I > would expect the CalDAV server to manage this property value, rather > than have the client attempt to set it. > > When a user logs in, the ACL standard defines a REPORT to ask "who am > I". With that report the client gets the mapping from the user's login > ID to a principal URL. > > Lisa > > > On Aug 26, 2004, at 1:05 PM, Bernard Desruisseaux wrote: > >> I see calendar creation more as a provisioning issue, and >> thus probably outside the scope of CalDAV. >> >> A user could find the location of his calendars by looking >> at the "calendars" property (see section 11.2) of his own >> principal resource (e.g., http://example.com/users/bernard) >> assuming the user knows the URL of his own principal resource. >> I don't actually know how he would though. >> >> Cheers, >> Bernard >> >> Cyrus Daboo wrote: >> >>> Presumably the client uses MKCOL to create a new calendar container, >>> but it has to include a body in the http request with suitable data >>> to indicate which of the new collection resource types it wants to >>> create. Or can it change the resourcetype after creating the >>> collection? If the former we need to define the http request body for >>> creating new collection resource types. Would that be a blob of xml? >>> The WebDAV spec does not define what MKCOL request bodies are.... >>> Also, who gets to create the event, alarm, todo etc collections >>> within the calendar resource? Presumably the server should do that >>> when MKCOL + http body is executed? Or is the client expected to do >>> create the component containers the first time it needs to write a >>> component? Again the MKCOL + http body issue would arise. >> >> >> >> _______________________________________________ >> Ietf-caldav mailing list >> Ietf-caldav@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > 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 i7QLp6pp002487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Aug 2004 14:51:07 -0700 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 i7QLXlo3023450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2004 17:33:47 -0400 Date: Thu, 26 Aug 2004 17:54:05 -0400 From: Cyrus Daboo To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] Creating a calendar Message-ID: <760679EC1863F6EBF80A38DC@plato.cyrusoft.com> In-Reply-To: <87845362-F7A6-11D8-AE89-000D93C1A604@opengroupware.org> References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> <87845362-F7A6-11D8-AE89-000D93C1A604@opengroupware.org> X-Mailer: Mulberry/4.0.0d1 (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-Scanned-By: MIMEDefang 2.39 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: Thu, 26 Aug 2004 21:51:08 -0000 Hi Helge, --On Thursday, August 26, 2004 11:26 PM +0200 Helge Hess wrote: >> But that does not help locating calendars for resources that are not >> associated with a principal e.g. public calendars, calendars for >> meeting rooms etc One could argue that you could use DASL to find >> those things, but I think having a NAMESPACE report would be better. > > Please elaborate. Why do you think that this would be better? I would expect the namespace data to be relatively static - hence a report will be more efficient than a search (less load on the server). It avoids the need to define arbitrary resourcetypes to cover the many different types one might want, and then expecting users to know what those types are when doing a search. e.g. what would the user/client search for if they wanted a list of calendars for all meeting rooms? The namespace report is flexible in that site admins get to define the structure and types for their calendar store hierarchy and the clients do not have to have any knowledge of what those types are in order to find them. It may well be that there are cases where the organisation of the calendar store makes it hard to express in a report like that, and the server should not be required to return any results if it cannot. In that case the client can fall back to DASL or some other out-of-band provisioning mechanism. -- 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 i7QLQ9po029795 for ; Thu, 26 Aug 2004 14:26:10 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0D2EF282BAD for ; Thu, 26 Aug 2004 23:26:09 +0200 (CEST) Received: from [192.168.102.125] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 9F8B1282B62 for ; Thu, 26 Aug 2004 23:26:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87845362-F7A6-11D8-AE89-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Creating a calendar Date: Thu, 26 Aug 2004 23:26:01 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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, 26 Aug 2004 21:26:10 -0000 On Aug 26, 2004, at 23:18, Cyrus Daboo wrote: > But that does not help locating calendars for resources that are not > associated with a principal e.g. public calendars, calendars for > meeting rooms etc One could argue that you could use DASL to find > those things, but I think having a NAMESPACE report would be better. Please elaborate. Why do you think that this would be better? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: daboo@isamet.com 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 i7QLFKpp028862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2004 14:15:22 -0700 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 i7QKvqo3022649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2004 16:57:52 -0400 Date: Thu, 26 Aug 2004 17:18:11 -0400 From: Cyrus Daboo To: Lisa Dusseault , Bernard Desruisseaux Subject: Re: [Ietf-caldav] Creating a calendar Message-ID: In-Reply-To: <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> References: <412E429A.4060504@oracle.com> <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0d1 (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-Scanned-By: MIMEDefang 2.39 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: Thu, 26 Aug 2004 21:15:23 -0000 Hi Lisa, --On Thursday, August 26, 2004 1:54 PM -0700 Lisa Dusseault wrote: > When a user logs in, the ACL standard defines a REPORT to ask "who am I". > With that report the client gets the mapping from the user's login ID to > a principal URL. But that does not help locating calendars for resources that are not associated with a principal e.g. public calendars, calendars for meeting rooms etc One could argue that you could use DASL to find those things, but I think having a NAMESPACE report would be better. -- Cyrus Daboo 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 i7QKscpp025114 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 26 Aug 2004 13:54:38 -0700 In-Reply-To: <412E429A.4060504@oracle.com> References: <412E429A.4060504@oracle.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20073DFE-F7A2-11D8-8DF1-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Creating a calendar Date: Thu, 26 Aug 2004 13:54:30 -0700 To: Bernard Desruisseaux X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Thu, 26 Aug 2004 20:54:39 -0000 Could be provisioning, yes. For example, a CalDAV server might create the collections only when the user first logs in to an authorized account (LDAP or other). Or there might be a Web page for requesting a calendar repository. I think this is not a requirement for CalDAV to cover but I may be wrong about the use cases. I also like the idea of looking at the principal resource to find out more information like where the user's calendar is homed, where the user's other file sharing space can be found, etc. CalDAV would only have to define a property on the principal resource for this to work -- the principal resources are locatable through special ACL REPORTs. I would expect the CalDAV server to manage this property value, rather than have the client attempt to set it. When a user logs in, the ACL standard defines a REPORT to ask "who am I". With that report the client gets the mapping from the user's login ID to a principal URL. Lisa On Aug 26, 2004, at 1:05 PM, Bernard Desruisseaux wrote: > I see calendar creation more as a provisioning issue, and > thus probably outside the scope of CalDAV. > > A user could find the location of his calendars by looking > at the "calendars" property (see section 11.2) of his own > principal resource (e.g., http://example.com/users/bernard) > assuming the user knows the URL of his own principal resource. > I don't actually know how he would though. > > Cheers, > Bernard > > Cyrus Daboo wrote: > >> Presumably the client uses MKCOL to create a new calendar container, >> but it has to include a body in the http request with suitable data >> to indicate which of the new collection resource types it wants to >> create. Or can it change the resourcetype after creating the >> collection? If the former we need to define the http request body for >> creating new collection resource types. Would that be a blob of xml? >> The WebDAV spec does not define what MKCOL request bodies are.... >> Also, who gets to create the event, alarm, todo etc collections >> within the calendar resource? Presumably the server should do that >> when MKCOL + http body is executed? Or is the client expected to do >> create the component containers the first time it needs to write a >> component? Again the MKCOL + http body issue would arise. > > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 i7QKYUpp020825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Aug 2004 13:34:33 -0700 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 i7QKH7o3021750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2004 16:17:07 -0400 Date: Thu, 26 Aug 2004 16:37:25 -0400 From: Cyrus Daboo To: Bernard Desruisseaux , CalDAV DevList Subject: Re: [Ietf-caldav] Creating a calendar Message-ID: <10E306F2C4CA4D160E3F410E@plato.cyrusoft.com> In-Reply-To: <412E429A.4060504@oracle.com> References: <412E429A.4060504@oracle.com> X-Mailer: Mulberry/4.0.0d1 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========54CD4866E66C8860203B==========" X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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: Thu, 26 Aug 2004 20:34:35 -0000 --==========54CD4866E66C8860203B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Bernard, --On Thursday, August 26, 2004 4:05 PM -0400 Bernard Desruisseaux wrote: > I see calendar creation more as a provisioning issue, and > thus probably outside the scope of CalDAV. I disagree - I expect users to be able to create, organize, delete etc a hierarchy of calendars and that must be possible via the caldav client. > A user could find the location of his calendars by looking > at the "calendars" property (see section 11.2) of his own > principal resource (e.g., http://example.com/users/bernard) > assuming the user knows the URL of his own principal resource. > I don't actually know how he would though. Actually one thing I would like to propose is the equivalent of the IMAP NAMESPACE extension. Specifically a REPORT that would list key URLs for the different caldav store paths a user's client should provision itself with. That would include a URL to the users personal calendars, one for shared (other users) calendars, and one for public calendars. In addition a URL to the principals collection would also be handy to make working with ACLs easy. In the process of our work I wrote something up on this and have attached a rough outline of that as a second text part to this message. I would like to know if this is something we should consider for caldav. -- Cyrus Daboo --==========54CD4866E66C8860203B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 2.2 Repository Organisation and Namepsace As per [CALDAV], calendar data may be scattered across multiple parts of a repository. However, clients need a generalised way to locate calendar stores within the repository to make browsing easier. Therefore a CalDAV server will define specific areas within the repository that are identified as containing (only) calendar resources. These areas will be identified by specific groupings indicating the nature of the calendar 'area' being described. This is akin to IMAP's NAMEPSACE extension which allows different areas within a mailstore to be identified. The CalDAV server will provide a special REPORT that returns the store namepsace information. There are several pre-defined areas: a. "Personal" - indicates the area that contains the currently authenticated user's own personal calendar resources. By default, all data within this hierarchy will be private to the user, but the user may choose to use WebDAV ACLs to expose specific resources to other users as appropriate. b. "Shared" - indicates an area that contains calendars for all individual users on the caldav server. Typically this area will be split into hierarchies for each user on the system. By default, all data within each user hierarchy will be private to that user, but any user may choose to use WebDAV ACLs to expose specific resources to other users as appropriate. NB The currently authenticated user's personal hierarchy will also appear in the "Shared" area. Clients may choose to suppress display of that when presenting users with a view of the "Shared" area, if they also present the "Personal" area separately. c. "Public" - indicates an area that contains calendars accessible to all users on the caldav server. Access control can be used to limit access to any resources within this area, but typically it would be accessible to all users. d. "Timezones" - indicates an area where the server stores a common "library" of iCalendar timezones that clients can use to build their own timezone lists. , See Section 8. e. "ACL-Users" - indicates an area where WebDAV ACL principles for users can be found. This area is provided to allow clients to lookup users when doing access control operations on calendars. Clients that do not manipulate access control information can ignore it. f. "ACL-Groups" - indicates an area where WebDAV ACL principles for groups can be found. This area is provided to allow clients to lookup groups when doing access control operations on calendars. Clients that do not manipulate access control information can ignore it. Servers MUST also permit the use of other areas, that will be user (server admin) defined. This allows an organisation to map their organisational structure into the CalDAV space to expose calendars for internal resources such as meeting rooms, specific devices (printers, copiers, shared terminals etc). The server MUST advertise such areas in the NAMESPACE report described in Section 6.1. Each area will have an associated display name and description in the NAMESPACE report results that can be used when presenting them to the user. Example: A server uses the following relative URIs for the standard areas (assuming the currently authenticated user is identified as "joe"): +--------------+----------------------+------------------------+ | Area | RURI | Display Name | +--------------+----------------------+------------------------+ | "Personal" | /calendars/user/joe | My Calendars | | "Shared" | /calendars/user | Other Users' Calendars | | "Public" | /calendars/public | Public Calendars | | "Timezones" | /calendars/timezones | | | "ACL-Users" | /principles/user | | | "ACL-Groups" | /principles/group | | +--------------+----------------------+------------------------+ In addition the server may advertise other areas: +------------+---------------------+-----------------------+ | Area | RURI | Display Name | +------------+---------------------+-----------------------+ | "Rooms" | /calendars/room | Meeting Room Bookings | | "Projects" | /calendars/projects | Project Timelines | +------------+---------------------+-----------------------+ 6.1 The 'calendar-store-namespace' report The namespace report is used by the client to determine the areas of the CalDAV server's repository where calendar data is stored. CalDAV servers can divide up their repository into different areas to group calendar data according to some functional meaning. Section 2.2 describes the areas that servers SHOULD support. 6.1.1 Request for 'calendar-store-namespace' The REPORT request-body MUST have the root element 'calendar-store-namespace' Section 10.1. Example: -------Client Request------- REPORT /caldav-root HTTP/1.1 Host: caldav.example.com Content-Type: text/xml; charset="utf-8" Content-Length: XXX > 6.1.2 Response for 'calendar-store-namespace' The response to this report is an XML document containing the namespace details. The XML document contains a single 'calendar-namespace-response' element Section 10.2, which contains zero or more 'calendar-namespace' elements for each namespace defined by the server. Each 'calendar-namespace' element contains a 'type' attribute identifying the namespace type, and an href element indicating the location of the resource. It may also contain a 'display-name' element and/or a 'description' element. Example: -------Server Response------- HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: xxxx /calendars/user/joe My Calendars Your calendars /calendars/user Other Users' Calendars Calendars belonging to other users that have been shared with you /calendars/public Public Calendars Calendars available to all users /calendars/timezones --==========54CD4866E66C8860203B==========-- X-Envelope-From: bernard.desruisseaux@oracle.com X-Envelope-To: Received: from agminet04.oracle.com (agminet04.oracle.com [141.146.126.231]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7QK64pp015565 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Aug 2004 13:06:04 -0700 Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.191.12]) by agminet04.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7QK5wD0007688 for ; Thu, 26 Aug 2004 13:05:58 -0700 Received: from localhost (localhost [127.0.0.1]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id i7QK5vwQ025076 for ; Thu, 26 Aug 2004 14:05:58 -0600 Received: from oracle.com (bdesruis-ca.ca.oracle.com [144.23.213.225]) by rgmgw3.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i7QK5oei024862; Thu, 26 Aug 2004 14:05:50 -0600 Message-ID: <412E429A.4060504@oracle.com> Date: Thu, 26 Aug 2004 16:05:46 -0400 From: Bernard Desruisseaux User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, fr-ca MIME-Version: 1.0 To: CalDAV DevList Subject: Re: [Ietf-caldav] Creating a calendar References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 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, 26 Aug 2004 20:06:05 -0000 I see calendar creation more as a provisioning issue, and thus probably outside the scope of CalDAV. A user could find the location of his calendars by looking at the "calendars" property (see section 11.2) of his own principal resource (e.g., http://example.com/users/bernard) assuming the user knows the URL of his own principal resource. I don't actually know how he would though. Cheers, Bernard Cyrus Daboo wrote: > Presumably the client uses MKCOL to create a new calendar container, but > it has to include a body in the http request with suitable data to > indicate which of the new collection resource types it wants to create. > Or can it change the resourcetype after creating the collection? If the > former we need to define the http request body for creating new > collection resource types. Would that be a blob of xml? The WebDAV spec > does not define what MKCOL request bodies are.... > > Also, who gets to create the event, alarm, todo etc collections within > the calendar resource? Presumably the server should do that when MKCOL + > http body is executed? Or is the client expected to do create the > component containers the first time it needs to write a component? Again > the MKCOL + http body issue would arise. > > X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7Q00Tpp007149 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 Aug 2004 17:00:32 -0700 In-Reply-To: References: <2F696BE7953BC7185C86CEDA@ninevah.cyrusoft.com> <4F48D930-F545-11D8-912D-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] The VALARM problem Date: Wed, 25 Aug 2004 17:00:21 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Thu, 26 Aug 2004 00:00:34 -0000 Since VALARMs are sub-components, what do you think about embedding them inside the body of a VEVENT (or whatever it is that uses them?) So if you GET a VEVENT, it would have BEGIN and END for the VEVENT component, and inside that, a set of BEGIN and ENDs for each VALARM if any are set. I was trying to think if there are any disadvantages to this, and there are a few, but t's not too bad. A client must download all events to see what the set of alarms might be -- it can't just use PROPFIND to list the alarms or SEARCH to list only the alarms that haven't happened yet. For any synchronizing client being run by the calendar owner, that's fine because they probably want to synchronize all the events. For clients acting on behalf of calendar "sharers", who want to browse through events and not alarms, it gets in the way slightly -- information that has to be filtered out if it is publicly readable. It's a kind of a compromise because modelling a VEVENT as a collection -- something with both a body and internal members -- seems to stretch WebDAV a little more. That's not necessarily a bad thing but it may cause a few glitches here and there with backward compatibility until clients catch up. Lisa On Aug 23, 2004, at 2:32 PM, Cyrus Daboo wrote: > Hi Lisa, > > --On Monday, August 23, 2004 1:45 PM -0700 Lisa Dusseault > wrote: > >> This is indeed a problem and I'm not sure how to deal with it. I'd >> prefer if VEVENTs are non-collection resources, because if they are >> collections it's more work to define what happens if you GET a VEVENT. >> Does the server have to take the VALARMS and package them up as part >> of >> the GET response? > > But doesn't your approach also have the same issue? If you GET the > resource, does that include the VALARMs bundled into the data? Note > that I am not proposing that the user does a GET on the collection, > but instead a GET on a resource within that collection. > > There is also the issue of PUT - PUT would have to decompose the data > to extract the alarms and store them and link them in to the property. > > I note that the collection model does make 'put' somewhat harder when > first creating the event in that it actually has to be an MKCOL > followed by a PUT or an MKCOL with an http request body that includes > the initial data. That is one downside. > > There is another advantage to using a collection to represent a > component: namely that the collection provides a useful location for > storing other meta-data about the component. For example, you > mentioned that you might want to store fairly large text blobs or > other data blobs with an event but did not want to store it in the > event data itself. Well you could just store it in a resource in the > event collection and have a property with a relative URL to that. > Also, if an event had an attachment referred to via a URL, the event > collection would be a good place to store the attachment data too. > >> My current approach, which hasn't been fully fleshed out in writing >> yet, >> was to make every calendar component be a single HTTP resource for >> consistency. Then each VEVENT that had one or more VALARMs associated >> with it, would have a property pointing to the VALARMs. It might be a >> multi-valued property like this: >> >> >> >> >> http://caldav.example.org/calendars/lisa/alarms/alarm_uid52> D: >> href> >> >> http://caldav.example.org/calendars/lisa/alarms/alarm_uid58> D: >> href> >> >> >> >> This would allow multiple VEVENTs to reference the same alarm. For >> example, a calendar application might suggest "standard sound alarm >> fifteen minutes before event" and every time the user simply accepts >> this default alarm, then the new VEVENT references the same old VALARM >> containing a relative time offset. I think this is what TRIGGER >> allows? > > The collection data model would also allow that, except that some of > the alarms could actually reside inside the parent component > collection and would be deleted/moved/copied along with the parent. > > I do like the idea of being able to have a common 'library' of > standard VALARMs that could be referenced. That would certainly make > setting alarms less painful on the client side. > >> Now that this has been fleshed out a little more, does it still seem >> like a bad approach? Can it be fixed up to make it a good approach? >> -- > > The problem of events etc moving between calendars still exists. With > your approach the server or client MUST also move the valarm resources > and adjust the valarm reference property each time otherwise the > possibility of stale references can arise (e.g. when the original > calendar is deleted or renamed). The collection model would not have > that problem as the valarm reference property would be relative to the > collection itself and the actual resource pointed to would move along > with the collection each time. > >> What are the disadvantages of having separate collections, or is it >> just >> the complexity that bothers? > > Complexity is one issue - but also looking at some of the calsify > discussions it may well be that we end up with a single type of > component in which case the extra level of hierarchy is superfluous - > but that is probably looking too far ahead. > > > > -- > Cyrus Daboo > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: daboo@isamet.com 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 i7PLDOpp026476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2004 14:13:25 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7PKuEo3023049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2004 16:56:15 -0400 Date: Wed, 25 Aug 2004 17:13:22 -0400 From: Cyrus Daboo To: Lisa Dusseault Subject: Re: [Ietf-caldav] Data model issue Message-ID: In-Reply-To: <3A009352-F6DB-11D8-8DF1-000A95B2BB72@osafoundation.org> References: <502E60ABB8712860F4375F73@ninevah.cyrusoft.com> <3A009352-F6DB-11D8-8DF1-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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, 25 Aug 2004 21:13:26 -0000 Hi Lisa, --On Wednesday, August 25, 2004 2:10 PM -0700 Lisa Dusseault wrote: > I agree with all of that. 'That' being the second of the two possible ways of doing it, right? > On Aug 25, 2004, at 2:06 PM, Cyrus Daboo wrote: > >> What is the 'raw' iCal data in each vevent etc resource? Is it a full >> iCalendar data object (i.e. BEGIN:VCALENDAR...END:VCALENDAR), or just >> the component (i.e. BEGIN:VEVENT...END:VEVENT)? >> >> If the former, that adds a lot of redundant information to each >> resource, given that the calendar-specific info could be gleaned from >> properties on the calendar collection that contains the components. >> >> If the later, we must require clients to check the VERSION/CALSCALE >> etc on the calendar collection to be sure it can handle components of >> that type. Plus I think the MIME type should not be text/calendar, but >> rather a new text/calendar-component type. -- 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 i7PLBDpp026290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2004 14:11:14 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7PKs2o3022929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2004 16:54:04 -0400 Date: Wed, 25 Aug 2004 17:11:10 -0400 From: Cyrus Daboo To: CalDAV DevList Message-ID: X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Creating a calendar 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, 25 Aug 2004 21:11:14 -0000 Presumably the client uses MKCOL to create a new calendar container, but it has to include a body in the http request with suitable data to indicate which of the new collection resource types it wants to create. Or can it change the resourcetype after creating the collection? If the former we need to define the http request body for creating new collection resource types. Would that be a blob of xml? The WebDAV spec does not define what MKCOL request bodies are.... Also, who gets to create the event, alarm, todo etc collections within the calendar resource? Presumably the server should do that when MKCOL + http body is executed? Or is the client expected to do create the component containers the first time it needs to write a component? Again the MKCOL + http body issue would arise. -- Cyrus Daboo X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7PLAopp026264 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 25 Aug 2004 14:10:52 -0700 In-Reply-To: <502E60ABB8712860F4375F73@ninevah.cyrusoft.com> References: <502E60ABB8712860F4375F73@ninevah.cyrusoft.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3A009352-F6DB-11D8-8DF1-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Data model issue Date: Wed, 25 Aug 2004 14:10:43 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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, 25 Aug 2004 21:10:53 -0000 I agree with all of that. lisa On Aug 25, 2004, at 2:06 PM, Cyrus Daboo wrote: > What is the 'raw' iCal data in each vevent etc resource? Is it a full > iCalendar data object (i.e. BEGIN:VCALENDAR...END:VCALENDAR), or just > the component (i.e. BEGIN:VEVENT...END:VEVENT)? > > If the former, that adds a lot of redundant information to each > resource, given that the calendar-specific info could be gleaned from > properties on the calendar collection that contains the components. > > If the later, we must require clients to check the VERSION/CALSCALE > etc on the calendar collection to be sure it can handle components of > that type. Plus I think the MIME type should not be text/calendar, but > rather a new text/calendar-component type. > > > -- > Cyrus Daboo > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 i7PL66pp025804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2004 14:06:08 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7PKmuo3022780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2004 16:48:57 -0400 Date: Wed, 25 Aug 2004 17:06:03 -0400 From: Cyrus Daboo To: CalDAV DevList Message-ID: <502E60ABB8712860F4375F73@ninevah.cyrusoft.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Data model issue 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, 25 Aug 2004 21:06:08 -0000 What is the 'raw' iCal data in each vevent etc resource? Is it a full iCalendar data object (i.e. BEGIN:VCALENDAR...END:VCALENDAR), or just the component (i.e. BEGIN:VEVENT...END:VEVENT)? If the former, that adds a lot of redundant information to each resource, given that the calendar-specific info could be gleaned from properties on the calendar collection that contains the components. If the later, we must require clients to check the VERSION/CALSCALE etc on the calendar collection to be sure it can handle components of that type. Plus I think the MIME type should not be text/calendar, but rather a new text/calendar-component type. -- 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 i7NLWxpp018759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2004 14:33:01 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7NLG5o3028297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2004 17:16:07 -0400 Date: Mon, 23 Aug 2004 17:32:55 -0400 From: Cyrus Daboo To: CalDAV DevList Subject: Re: [Ietf-caldav] The VALARM problem Message-ID: In-Reply-To: <4F48D930-F545-11D8-912D-000A95B2BB72@osafoundation.org> References: <2F696BE7953BC7185C86CEDA@ninevah.cyrusoft.com> <4F48D930-F545-11D8-912D-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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, 23 Aug 2004 21:33:02 -0000 Hi Lisa, --On Monday, August 23, 2004 1:45 PM -0700 Lisa Dusseault wrote: > This is indeed a problem and I'm not sure how to deal with it. I'd > prefer if VEVENTs are non-collection resources, because if they are > collections it's more work to define what happens if you GET a VEVENT. > Does the server have to take the VALARMS and package them up as part of > the GET response? But doesn't your approach also have the same issue? If you GET the resource, does that include the VALARMs bundled into the data? Note that I am not proposing that the user does a GET on the collection, but instead a GET on a resource within that collection. There is also the issue of PUT - PUT would have to decompose the data to extract the alarms and store them and link them in to the property. I note that the collection model does make 'put' somewhat harder when first creating the event in that it actually has to be an MKCOL followed by a PUT or an MKCOL with an http request body that includes the initial data. That is one downside. There is another advantage to using a collection to represent a component: namely that the collection provides a useful location for storing other meta-data about the component. For example, you mentioned that you might want to store fairly large text blobs or other data blobs with an event but did not want to store it in the event data itself. Well you could just store it in a resource in the event collection and have a property with a relative URL to that. Also, if an event had an attachment referred to via a URL, the event collection would be a good place to store the attachment data too. > My current approach, which hasn't been fully fleshed out in writing yet, > was to make every calendar component be a single HTTP resource for > consistency. Then each VEVENT that had one or more VALARMs associated > with it, would have a property pointing to the VALARMs. It might be a > multi-valued property like this: > > > > > http://caldav.example.org/calendars/lisa/alarms/alarm_uid52 href> > > http://caldav.example.org/calendars/lisa/alarms/alarm_uid58 href> > > > > This would allow multiple VEVENTs to reference the same alarm. For > example, a calendar application might suggest "standard sound alarm > fifteen minutes before event" and every time the user simply accepts > this default alarm, then the new VEVENT references the same old VALARM > containing a relative time offset. I think this is what TRIGGER allows? The collection data model would also allow that, except that some of the alarms could actually reside inside the parent component collection and would be deleted/moved/copied along with the parent. I do like the idea of being able to have a common 'library' of standard VALARMs that could be referenced. That would certainly make setting alarms less painful on the client side. > Now that this has been fleshed out a little more, does it still seem > like a bad approach? Can it be fixed up to make it a good approach? -- The problem of events etc moving between calendars still exists. With your approach the server or client MUST also move the valarm resources and adjust the valarm reference property each time otherwise the possibility of stale references can arise (e.g. when the original calendar is deleted or renamed). The collection model would not have that problem as the valarm reference property would be relative to the collection itself and the actual resource pointed to would move along with the collection each time. > What are the disadvantages of having separate collections, or is it just > the complexity that bothers? Complexity is one issue - but also looking at some of the calsify discussions it may well be that we end up with a single type of component in which case the extra level of hierarchy is superfluous - but that is probably looking too far ahead. -- Cyrus Daboo 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 i7NKiCpq015754 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 Aug 2004 13:45:05 -0700 In-Reply-To: <2F696BE7953BC7185C86CEDA@ninevah.cyrusoft.com> References: <2F696BE7953BC7185C86CEDA@ninevah.cyrusoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F48D930-F545-11D8-912D-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] The VALARM problem Date: Mon, 23 Aug 2004 13:45:03 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 20:45:06 -0000 This is indeed a problem and I'm not sure how to deal with it. I'd prefer if VEVENTs are non-collection resources, because if they are collections it's more work to define what happens if you GET a VEVENT. Does the server have to take the VALARMS and package them up as part of the GET response? My current approach, which hasn't been fully fleshed out in writing yet, was to make every calendar component be a single HTTP resource for consistency. Then each VEVENT that had one or more VALARMs associated with it, would have a property pointing to the VALARMs. It might be a multi-valued property like this: http://caldav.example.org/calendars/lisa/alarms/alarm_uid52 http://caldav.example.org/calendars/lisa/alarms/alarm_uid58 This would allow multiple VEVENTs to reference the same alarm. For example, a calendar application might suggest "standard sound alarm fifteen minutes before event" and every time the user simply accepts this default alarm, then the new VEVENT references the same old VALARM containing a relative time offset. I think this is what TRIGGER allows? Now that this has been fleshed out a little more, does it still seem like a bad approach? Can it be fixed up to make it a good approach? -- e.g. the proposed property could have each alarm's UID as well as the URL... As for the benefit of separate collections, the reasons I went with separate collections were: - to make PROPFIND work well. PROPFIND works best when querying a set of items with the same properties. And PROPFIND should work well so that clients can synchronize calendar data for offline use. - to make access control easier -- my VJOURNALs are likely to be private and my VEVENTS more publicly readable, so with separate collections we can use WebDAV access control to accomplish that without any more special thought. - to simplify life for clients that only want to support VEVENTS even when viewing the calendar of some other user that has more complex data What are the disadvantages of having separate collections, or is it just the complexity that bothers? It was my hunch that the separate collections added complexity would be "paid for" by the advantages I cited, but of course that depends on many factors that vary by implementation. Lisa On Aug 23, 2004, at 11:48 AM, Cyrus Daboo wrote: > Currently caldav has VALARMs split out into their own collection, but > iCal has VALARMs as sub-components of VEVENTs etc. This causes a > number of problems: > > 1) If the user fetches the VEVENT resource does that include the > VALARM data as well? > 2) What happens if the VEVENT resource is MOVE'd or COPY'd between > calendar collections? Who gets to move/copy the VALARMS - the server > or client? > 3) What happens if the user sets an ACL on the VEVENT resource? Should > the ACL also be set on the VALARM resource? Who does that - the server > or client? > 4) What happens when a VEVENT resource is deleted? Who deletes the > corresponding VALARM resource - the server or client? > > An alternative to the current design that would better model the iCal > data format would be to make iCal components (VEVENTs etc) collections > rather than resources. Inside the collection would be a resource that > represents the actual iCal data (e.g. > /mycalendar/vevent/1234/index.ics). This would allow the concept of > embedded components that iCal has. i.e. a VALARM component collection > could be included inside the VEVENT component collection that 'owns' > it (e.g. /mycalendar/vevent/1234/alarm1/index.ics would be the > resource for the iCal data of an alarm). This model pretty much solves > all the issues above, except perhaps for (1). It still keeps alarms as > separate resources which can have their own set of ACLs etc. > > At the same time I would also like to question the benefit of having > separate collections for VEVENT, VTODO, VJOURNAL. Why not have all of > those types of component stored at the same hierarchy level and simply > have a component-type property that describes what they are? > > -- > Cyrus Daboo > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 i7NJf0pp011902 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 23 Aug 2004 12:41:03 -0700 In-Reply-To: <488DBC7CD3602F9F3DC1DE1E@ninevah.local> References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> <488DBC7CD3602F9F3DC1DE1E@ninevah.local> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5870A076-F53C-11D8-918F-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: [Ietf-caldav] What locks really do (was: Re: Alternative to splitting out components) Date: Mon, 23 Aug 2004 12:40:53 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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: Mon, 23 Aug 2004 19:41:04 -0000 > >> - Good multi-author coordination changing different events, or even >> changing different properties of same event --> shared calendars like >> meeting rooms >> >> This is presumably an issue with lock contention when sharing a >> calendar? >> >> Not if single resources are locked. Assuming the client even locks a >> single event (it doesn't need to if it does things properly) that >> event >> lock wouldn't conflict with other event locks on the same calendar. >> (And >> more advanced clients still have the choice of obtaining multiple >> locks.) > > In theory a lock isn't needed for the single resource case as PATCH is > atomic. Indeed, if the server actually uses a database backend to > store the iCalendar object it may well store the components separately > so that individual component patches do not block access to other > components. I think it's important to understand what locks actually provide for single file editing in multi-author scenarios, that cannot be provided by ETags or any other non-reservation-based solution. The way PATCH avoids lost updates is the same way PUT avoids lost updates -- sending the ETag. Certainly ETags prevent the "lost update" case: http://www.w3.org/1999/04/Editing/ However, ETags (whether used with PATCH or PUT) do not prevent the "lost work" case where a user makes a bunch of changes then has to throw them away. This is most often seen in shared documents like a team's project spreadsheet. Multiple users frequently edit the spreadsheet to update status, particularly before a meeting -- I've seen this in real life and it's frustrating. Let's say I download the spreadsheet without locking it, and I update my project status and add a few new rows or whatever. Then when I try to save the document back to the repository the client that uses ETags properly would detect whether the server document had changed. If it did, my client would warn me: "The document you are editing has been changed on the server. Do you want to throw away your changes or overwrite the changes on the server?" It's more socially acceptable to throw away my own changes ("lost work"), download the document again, and start from scratch. This "lost work" case can be reduced by having the client poll as long as the document stays open, to see if it changed -- thus I'm likely to waste on average half as much time in cases where another user is changing the document. Or the client can save changes more often, but that's not always desirable. Sometimes documents can be merged, but again that only reduces the problem because some changes are unmergeable. In calendaring, we can expect conflicting changes from online users to occur less often. Users don't typically edit an event for long periods of time. Still this can happen, particularly if a user starts editing an event then gets distracted by something else, then tries to return to finish editing the event and save the changes. With locks, calendaring clients can choose to prevent this problem in the first place anytime the user is online. We even have a chance for the user to find out who is editing the event before starting to make changes. Lisa 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 i7NImYpp007752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2004 11:48:35 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7NIVho3024604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2004 14:31:44 -0400 Date: Mon, 23 Aug 2004 14:48:31 -0400 From: Cyrus Daboo To: CalDAV DevList Message-ID: <2F696BE7953BC7185C86CEDA@ninevah.cyrusoft.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] The VALARM problem 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, 23 Aug 2004 18:48:36 -0000 Currently caldav has VALARMs split out into their own collection, but iCal has VALARMs as sub-components of VEVENTs etc. This causes a number of problems: 1) If the user fetches the VEVENT resource does that include the VALARM data as well? 2) What happens if the VEVENT resource is MOVE'd or COPY'd between calendar collections? Who gets to move/copy the VALARMS - the server or client? 3) What happens if the user sets an ACL on the VEVENT resource? Should the ACL also be set on the VALARM resource? Who does that - the server or client? 4) What happens when a VEVENT resource is deleted? Who deletes the corresponding VALARM resource - the server or client? An alternative to the current design that would better model the iCal data format would be to make iCal components (VEVENTs etc) collections rather than resources. Inside the collection would be a resource that represents the actual iCal data (e.g. /mycalendar/vevent/1234/index.ics). This would allow the concept of embedded components that iCal has. i.e. a VALARM component collection could be included inside the VEVENT component collection that 'owns' it (e.g. /mycalendar/vevent/1234/alarm1/index.ics would be the resource for the iCal data of an alarm). This model pretty much solves all the issues above, except perhaps for (1). It still keeps alarms as separate resources which can have their own set of ACLs etc. At the same time I would also like to question the benefit of having separate collections for VEVENT, VTODO, VJOURNAL. Why not have all of those types of component stored at the same hierarchy level and simply have a component-type property that describes what they are? -- 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 i7NGEUpp026583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2004 09:14:31 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7NFvdo3020319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2004 11:57:41 -0400 Date: Mon, 23 Aug 2004 12:14:26 -0400 From: Cyrus Daboo To: CalDAV DevList Subject: Re: [Ietf-caldav] CalDAV Client work? Message-ID: X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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, 23 Aug 2004 16:14:32 -0000 Hi Helge, --On Wednesday, August 11, 2004 3:13 PM +0000 Helge Hess wrote: > anyone working on client software which implements CalDAV? > > Lisa, can we expect Chandler to implement CalDAV any time soon? I guess > it would probably synchronize server data into its own repository > instead of having a "live" connection? > > I think the OGo project would invest some work into adding CalDAV as a > protocol. We already implement some parts of Exchange WebDAV protocol > and patches for CalDAV shouldn't be too much work. Having some client > vendor to work with would be of course great ;-) We are working on a client and server caldav solution. The client solution will be built into our email client Mulberry, and the server will be built around a new caldav module for apache. Work on both of these is progressing. In fact I would say we have reached the point where we now need to have a stable spec to work off - so we are very interested in getting caldav work done asap! Interoperability has always been a key issue for us so we happy to work with other client or server solutions to achieve that. -- 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 i7LGeKpp031778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Aug 2004 09:40:22 -0700 Received: from ninevah.cyrusoft.com (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7LGNmo3017718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Aug 2004 12:23:50 -0400 Date: Sat, 21 Aug 2004 12:40:17 -0400 From: Cyrus Daboo To: CalDAV DevList Message-ID: <18C1D0D34C2CDCC482730A8E@ninevah.local> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Additional required properties 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: Sat, 21 Aug 2004 16:40:22 -0000 In Section 10 of the current draft I would like to see the following additional required properties: sequence - the component SEQUENCE property recurrence-id - the component RECURRENCE-ID property has-recurrence - boolean that indicates the component has at least one of RRULE, RDATE, EXRULE, EXDATE has-alarm - boolean that indicates component has at least one embedded VALARM has-attachment - boolean that indicates component has at least one ATTACH property -- 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 i7LGcDpo031673 for ; Sat, 21 Aug 2004 09:38:13 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 038FF27A38E for ; Sat, 21 Aug 2004 18:37:55 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 92A76279F0C for ; Sat, 21 Aug 2004 18:37:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78B75A1C-F390-11D8-B6E4-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Alternative to splitting out components Date: Sat, 21 Aug 2004 18:38:03 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 16:38:14 -0000 On Aug 21, 2004, at 18:18, Cyrus Daboo wrote: >> No, its not fuzzy at all. Its just a different concept and one which >> is >> even gaining popularity in mail applications. There are few mail >> applications now which do not support query folders (or virtual >> folders >> or smart folders, whatever they are called ;-) > The virtual/smart/query folder support right quite happily gets by > with the ACL per-mailbox model not the ACL per-message model. Well, I guess this is getting off topic. With query folders the user looses the association of an object with its folder ACL because storage locations gets irrelevant for the user. So even if its internally implemented as per-folder ACLs it needs to be shown as ACLs attached to the object in the UI. If you want we can continue this discussion in private mail, I don't think it belongs here ;-) Lets get back on track by realizing that there all four variants are used in practice: no ACL, ACL per folder, ACL per object or both. To be interoperable, CalDAV needs to take this into account. I don't think this should be about explaining any vendor how he is supposed to do things. > Well I have been focused on users sharing mailboxes in IMAP for a long > time - I suspect a lot of other IMAP vendors would say the same. OK. No offense was intended and the topic isn't IMAP4 anyway. (my main point was that emails are a very different kind of object not comparable to an event - we may or may not agree on that, not worth discussion in either case ;-) > One of the things I would like to propose is the equivalent of IMAP's > NAMESPACE command - basically a WebDAV report that would return base > URLs for private, shared and public calendar hierarchies on the > server. Why do I need a report for that, isn't that already covered by a DASL query on the collection type? 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 i7LGJ8pp030881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Aug 2004 09:19:09 -0700 Received: from ninevah.cyrusoft.com (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7LG2Uo3017356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Aug 2004 12:02:33 -0400 Date: Sat, 21 Aug 2004 12:18:59 -0400 From: Cyrus Daboo To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] Alternative to splitting out components Message-ID: In-Reply-To: References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 16:19:10 -0000 Hi Helge, --On Saturday, August 21, 2004 2:42 AM +0200 Helge Hess wrote: >> Certainly in the case of IMAP per-mailbox ACLs are sufficient. The >> thought of having per-message ACLs is scary - and I think that boils >> down to the user experience - per-message ACLs would really make the >> UI too fuzzy in terms of maintaining a clear distinction between what >> might be shared or not. I think the same would apply to events in >> calendars. > > No, its not fuzzy at all. Its just a different concept and one which is > even gaining popularity in mail applications. There are few mail > applications now which do not support query folders (or virtual folders > or smart folders, whatever they are called ;-) The virtual/smart/query folder support right quite happily gets by with the ACL per-mailbox model not the ACL per-message model. >> (*) There are obviously tradeoffs in the server performance of >> single-resource-per-calendar vs single-resource-per-component models - >> I am comparing this to the similar case of mailstores that use one >> file per-mailbox or one file per-message models. > > The comparison with mail came up before, I think it is _very_ dangerous > to draw this. Mail is an inherently single-user thing, sharing them is > the exception (eg IMAP4 doesn't even allow an update operation which can > keep object identity) > This is different for calendars which are conceptually very focused on > sharing. Well I have been focused on users sharing mailboxes in IMAP for a long time - I suspect a lot of other IMAP vendors would say the same. In fact that is one of the major reasons why a lot of our customers use IMAP in the first place. One of the things I would like to propose is the equivalent of IMAP's NAMESPACE command - basically a WebDAV report that would return base URLs for private, shared and public calendar hierarchies on the server. That is important from a client 'provisioning' standpoint in that it avoids the need to give users that configuration data and allows the server to be flexible in how it manages the hierarchy. There are other things it would be useful for a caldav client to know e.g. the URL to the principles for ACL users and groups, and those could also be included in the report. -- Cyrus Daboo X-Envelope-From: daboo@isamet.com 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 i7LG1Epp030194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Aug 2004 09:01:15 -0700 Received: from ninevah.cyrusoft.com (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7LFieo3017033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Aug 2004 11:44:43 -0400 Date: Sat, 21 Aug 2004 12:01:08 -0400 From: Cyrus Daboo To: Lisa Dusseault Subject: Re: [Ietf-caldav] Alternative to splitting out components Message-ID: <488DBC7CD3602F9F3DC1DE1E@ninevah.local> In-Reply-To: References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 16:01:16 -0000 Hi Lisa, --On Friday, August 20, 2004 11:24 PM -0700 Lisa Dusseault wrote: > > > > - Attach conversations to events > > What are 'conversations' in this context? > > A pretty fuzzy Chandler concept -- just assume it's a fair amount of > text, possibly a fair bit larger than the iCalendar data itself. If the text is that large would you even want to store it as a property (by value) as opposed to store a URL to it and have the actual data reside elsewhere? > - Keep very old events around --> keep very large calendars > > Large calendars would not be a problem (* see below for a comment on > this): in theory it would be possible for a caldav server to disable GET > and PUT on the calendar file resource and only allow PROPFIND, REPORT and > PATCH as the means to access and change components. That would force the > client (authors) to think about exactly what they want and only ask for > that. > > Ahhh, but now you see you're going down the path of reinventing > mechanisms to handle sub-sections of a calendar, rather than using the > mechanisms the protocol provides for you. We could possibly define > simpler mechanisms than GET, PUT, and remembering ETags for each event; > but it wouldn't be as well-tested and it would become increasingly unlike > HTTP. Agreed - we should not try to turn HTTP/WebDAV into a new protocol for this. > - Good multi-author coordination changing different events, or even > changing different properties of same event --> shared calendars like > meeting rooms > > This is presumably an issue with lock contention when sharing a calendar? > > Not if single resources are locked. Assuming the client even locks a > single event (it doesn't need to if it does things properly) that event > lock wouldn't conflict with other event locks on the same calendar. (And > more advanced clients still have the choice of obtaining multiple locks.) In theory a lock isn't needed for the single resource case as PATCH is atomic. Indeed, if the server actually uses a database backend to store the iCalendar object it may well store the components separately so that individual component patches do not block access to other components. > - Fast browsing to "what's on this user's calendar today" > > A report can easily handle that for either model. > > Why redefine what PROPFIND already does in the multi-resource model? I'd > rather minimize the new things we need to design. My understating is that PROPFIND with the currently defined set of properties isn't enough - you need a report that can do recurrence expansion to ensure recurrence instances within the 'today range' are returned. PROPFIND only returns dtstart/dtend of the initial instances. Of course we could define an 'rdates' property that contains the expansion of a recurrence that PROPFIND could return - but then you have to deal with unbounded rrules. > - Selective permissions > > Do you mean per-component ACLs? i.e. a user has read access to one > component, but not another in the same calendar? I really wonder what the > benefit of that is over just having per-calendar ACLs. Certainly in the > case of IMAP per-mailbox ACLs are sufficient. The thought of having > per-message ACLs is scary - and I think that boils down to the user > experience - per-message ACLs would really make the UI too fuzzy in terms > of maintaining a clear distinction between what might be shared or not. I > think the same would apply to events in calendars. > > It wouldn't be required for all clients, but it's certainly a Chandler > use case. OK. > Don't forget that a PROPFIND can get a named property -- like the ETag -- > for every item in a collection. Here's how: (Right - with the current implementation work I am doing I do use PROPFIND to get the etag in cases where it is not automatically returned by the server - e.g. Apache does not return ETag: header on PUT requests). > C-->S > PROPFIND /repository/lisa/calendar/ HTTP/1.1 > Depth: 1 > Content-type: text/xml > > > > > > > > > [Now client compares the resulting list of ETags/URLs to the table of > locally stored ETags/URLs. For each new ETag, pipeline:] > > C-->S > GET /repository/lisa/calendar/new-event-on-server HTTP/1.1 > > [Don't forget to store the new ETag for each of these. Now client > compares the resources flagged as "dirty" locally, if there are any, > "dirty" meaning local changes were made:] > > C-->S > PUT /repository/lisa/calendar/new-event-on-client HTTP/1.1 > ... > > [Again don't forget to store the new ETag in the response to each of > these.] > > > In this example I oversimplified the problem of what to do with an event > that has changed both on the server and on the client, if the client made > changes while offline and chose not to lock the file. If the client > allows offline changes it has to have additional logic to deal with > conflicts. OK - the above example involves at least one PUT or GET for each changed resource. Of course clients can pipeline those for efficiency but it is still a potential performance pitfall IMHO. Is there anyone here interested in using caldav with mobile devices? I don't know whether we want to make efficient mobile device performance a requirement for caldav or not. Given the experience with IMAP where the lemonade group are having to retrofit IMAP with functionality for mobile devices I think it would be good if we can get that right from the outset. It might be enough to say that will be defined later by adding 'batch' type requests similar to the BPROPFIND stuff that Helge mentioned. Presumably the experience with Exchange did show that was important to have. -- Cyrus Daboo X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7L6Olpp031235 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 20 Aug 2004 23:24:50 -0700 In-Reply-To: <1CCA0C00F94DD600561A9466@ninevah.local> References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/alternative; boundary=Apple-Mail-3-945647020 Message-Id: From: Lisa Dusseault Subject: Re: [Ietf-caldav] Alternative to splitting out components Date: Fri, 20 Aug 2004 23:24:40 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 06:24:54 -0000 --Apple-Mail-3-945647020 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > >> - Attach conversations to events > > What are 'conversations' in this context? A pretty fuzzy Chandler concept -- just assume it's a fair amount of text, possibly a fair bit larger than the iCalendar data itself. > >> - Keep very old events around --> keep very large calendars > > Large calendars would not be a problem (* see below for a comment on > this): in theory it would be possible for a caldav server to disable > GET and PUT on the calendar file resource and only allow PROPFIND, > REPORT and PATCH as the means to access and change components. That > would force the client (authors) to think about exactly what they want > and only ask for that. Ahhh, but now you see you're going down the path of reinventing mechanisms to handle sub-sections of a calendar, rather than using the mechanisms the protocol provides for you. We could possibly define simpler mechanisms than GET, PUT, and remembering ETags for each event; but it wouldn't be as well-tested and it would become increasingly unlike HTTP. > >> - Good multi-author coordination changing different events, or even >> changing different properties of same event --> shared calendars like >> meeting rooms > > This is presumably an issue with lock contention when sharing a > calendar? Not if single resources are locked. Assuming the client even locks a single event (it doesn't need to if it does things properly) that event lock wouldn't conflict with other event locks on the same calendar. (And more advanced clients still have the choice of obtaining multiple locks.) > >> - Fast browsing to "what's on this user's calendar today" > > A report can easily handle that for either model. Why redefine what PROPFIND already does in the multi-resource model? I'd rather minimize the new things we need to design. > >> - Selective permissions > > Do you mean per-component ACLs? i.e. a user has read access to one > component, but not another in the same calendar? I really wonder what > the benefit of that is over just having per-calendar ACLs. Certainly > in the case of IMAP per-mailbox ACLs are sufficient. The thought of > having per-message ACLs is scary - and I think that boils down to the > user experience - per-message ACLs would really make the UI too fuzzy > in terms of maintaining a clear distinction between what might be > shared or not. I think the same would apply to events in calendars. It wouldn't be required for all clients, but it's certainly a Chandler use case. > >> IOW, I think it is in fact simple, but too simplistic. >>> We could consider another way to accomplish the client simplicity you >> propose at the cost of server complexity: require the server to >> provide >> *both* views. I'm worried that this would require not only more >> server >> work but also have some conflicts that we'd have to figure out how to >> deal with. E.g. it doesn't really help multi-author scenarios if the >> single-file calendar is always being locked by slow clients. > > I think that is pretty much what I proposed before with the Level > 1/Level 2 type behaviour, but now think Level 2 is too complex. > > My main concern right now is really with the on-the-wire complexity - > I want to keep the requests to a minimum and I think the > one-resource-per-calendar does do that. Can you explain how you see > the on-the-wire-behaviour for doing things like sync'ing an entire > calendar with the current model? Don't forget that a PROPFIND can get a named property -- like the ETag -- for every item in a collection. Here's how: C-->S PROPFIND /repository/lisa/calendar/ HTTP/1.1 Depth: 1 Content-type: text/xml [Now client compares the resulting list of ETags/URLs to the table of locally stored ETags/URLs. For each new ETag, pipeline:] C-->S GET /repository/lisa/calendar/new-event-on-server HTTP/1.1 [Don't forget to store the new ETag for each of these. Now client compares the resources flagged as "dirty" locally, if there are any, "dirty" meaning local changes were made:] C-->S PUT /repository/lisa/calendar/new-event-on-client HTTP/1.1 ... [Again don't forget to store the new ETag in the response to each of these.] In this example I oversimplified the problem of what to do with an event that has changed both on the server and on the client, if the client made changes while offline and chose not to lock the file. If the client allows offline changes it has to have additional logic to deal with conflicts. > > > > (*) There are obviously tradeoffs in the server performance of > single-resource-per-calendar vs single-resource-per-component models - > I am comparing this to the similar case of mailstores that use one > file per-mailbox or one file per-message models. Some operations > perform better in each of the different models. Also things like > backup/restore perform better for the per-message as opposed to > per-mailbox model. But that level of detail in server implementation > should not be a consideration. > > -- > Cyrus Daboo --Apple-Mail-3-945647020 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII - Attach conversations to events What are 'conversations' in this context? A pretty fuzzy Chandler concept -- just assume it's a fair amount of text, possibly a fair bit larger than the iCalendar data itself. - Keep very old events around --> keep very large calendars Large calendars would not be a problem (* see below for a comment on this): in theory it would be possible for a caldav server to disable GET and PUT on the calendar file resource and only allow PROPFIND, REPORT and PATCH as the means to access and change components. That would force the client (authors) to think about exactly what they want and only ask for that. Ahhh, but now you see you're going down the path of reinventing mechanisms to handle sub-sections of a calendar, rather than using the mechanisms the protocol provides for you. We could possibly define simpler mechanisms than GET, PUT, and remembering ETags for each event; but it wouldn't be as well-tested and it would become increasingly unlike HTTP. - Good multi-author coordination changing different events, or even changing different properties of same event --> shared calendars like meeting rooms This is presumably an issue with lock contention when sharing a calendar? Not if single resources are locked. Assuming the client even locks a single event (it doesn't need to if it does things properly) that event lock wouldn't conflict with other event locks on the same calendar. (And more advanced clients still have the choice of obtaining multiple locks.) - Fast browsing to "what's on this user's calendar today" A report can easily handle that for either model. Why redefine what PROPFIND already does in the multi-resource model? I'd rather minimize the new things we need to design. - Selective permissions Do you mean per-component ACLs? i.e. a user has read access to one component, but not another in the same calendar? I really wonder what the benefit of that is over just having per-calendar ACLs. Certainly in the case of IMAP per-mailbox ACLs are sufficient. The thought of having per-message ACLs is scary - and I think that boils down to the user experience - per-message ACLs would really make the UI too fuzzy in terms of maintaining a clear distinction between what might be shared or not. I think the same would apply to events in calendars. It wouldn't be required for all clients, but it's certainly a Chandler use case. IOW, I think it is in fact simple, but too simplistic. We could consider another way to accomplish the client simplicity you propose at the cost of server complexity: require the server to provide *both* views. I'm worried that this would require not only more server work but also have some conflicts that we'd have to figure out how to deal with. E.g. it doesn't really help multi-author scenarios if the single-file calendar is always being locked by slow clients. I think that is pretty much what I proposed before with the Level 1/Level 2 type behaviour, but now think Level 2 is too complex. My main concern right now is really with the on-the-wire complexity - I want to keep the requests to a minimum and I think the one-resource-per-calendar does do that. Can you explain how you see the on-the-wire-behaviour for doing things like sync'ing an entire calendar with the current model? Don't forget that a PROPFIND can get a named property -- like the ETag -- for every item in a collection. Here's how: Courier CEC-->S PROPFIND /repository/lisa/calendar/ HTTP/1.1 Depth: 1 Content-type: text/xml < < < < < < [Now client compares the resulting list of ETags/URLs to the table of locally stored ETags/URLs. For each new ETag, pipeline:] Courier CEC-->S GET /repository/lisa/calendar/new-event-on-server HTTP/1.1 [Don't forget to store the new ETag for each of these. Now client compares the resources flagged as "dirty" locally, if there are any, "dirty" meaning local changes were made:] Courier CEC-->S PUT /repository/lisa/calendar/new-event-on-client HTTP/1.1 ... [Again don't forget to store the new ETag in the response to each of these.] In this example I oversimplified the problem of what to do with an event that has changed both on the server and on the client, if the client made changes while offline and chose not to lock the file. If the client allows offline changes it has to have additional logic to deal with conflicts. (*) There are obviously tradeoffs in the server performance of single-resource-per-calendar vs single-resource-per-component models - I am comparing this to the similar case of mailstores that use one file per-mailbox or one file per-message models. Some operations perform better in each of the different models. Also things like backup/restore perform better for the per-message as opposed to per-mailbox model. But that level of detail in server implementation should not be a consideration. -- Cyrus Daboo --Apple-Mail-3-945647020-- 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 i7L3YOpp022705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2004 20:34:25 -0700 Received: from ninevah.cyrusoft.com (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7L3Hro3003626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2004 23:17:58 -0400 Date: Fri, 20 Aug 2004 23:34:17 -0400 From: Cyrus Daboo To: TimHare@comcast.net, ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Alternative to splitting out components Message-ID: <23E71023F33DB4CAD6A45F3F@ninevah.local> In-Reply-To: <6.1.1.1.0.20040820231253.027d4eb0@mail.comcast.net> References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> <6.1.1.1.0.20040820231253.027d4eb0@mail.comcast.net> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 03:34:26 -0000 Hi Tim, --On Friday, August 20, 2004 11:15 PM -0400 TimHare@comcast.net wrote: >> Do you mean per-component ACLs? i.e. a user has read access to one >> component, but not another in the same calendar? I really wonder what >> the benefit of that is over just having per-calendar ACLs. Certainly in >> the case of IMAP per-mailbox ACLs are sufficient. The thought of having >> per-message ACLs is scary - and I think that boils down to the user >> experience - per-message ACLs would really make the UI too fuzzy in >> terms of maintaining a clear distinction between what might be shared >> or not. I think the same would apply to events in calendars. > > > In many organizations, it is desirable to allow, for example, one's > subordinates to put reminders (VTODOs possibly) on one's calendar but not > meetings. This wouldn't to me, be a per-individual-component ACL, but a > per-component-type ACL and would be useful. I would consider that as part of the scheduling process rather than ACLs per se, but we are going to have to have some sort of ACL model for controlling who is allowed to automatically schedule events etc. That needs to be more than just who can write events/todos into a particular collection (which is what basic ACL will do), but it must allow rules as in 'xxx is allowed to automatically schedule events in the period 9 am - 5 pm, Monday - Friday' etc. -- Cyrus Daboo X-Envelope-From: TimHare@comcast.net X-Envelope-To: Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7L3Mkpo022024 for ; Fri, 20 Aug 2004 20:22:46 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc11) with SMTP id <2004082103223901100bti2je> (Authid: TimHare); Sat, 21 Aug 2004 03:22:39 +0000 Message-Id: <6.1.1.1.0.20040820231253.027d4eb0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Fri, 20 Aug 2004 23:15:44 -0400 To: ietf-caldav@osafoundation.org From: TimHare@comcast.net Subject: Re: [Ietf-caldav] Alternative to splitting out components In-Reply-To: <1CCA0C00F94DD600561A9466@ninevah.local> References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 03:22:46 -0000 At 07:51 PM 8/20/04, Cyrus Daboo wrote: >> - Selective permissions > >Do you mean per-component ACLs? i.e. a user has read access to one >component, but not another in the same calendar? I really wonder what the >benefit of that is over just having per-calendar ACLs. Certainly in the >case of IMAP per-mailbox ACLs are sufficient. The thought of having >per-message ACLs is scary - and I think that boils down to the user >experience - per-message ACLs would really make the UI too fuzzy in terms >of maintaining a clear distinction between what might be shared or not. I >think the same would apply to events in calendars. In many organizations, it is desirable to allow, for example, one's subordinates to put reminders (VTODOs possibly) on one's calendar but not meetings. This wouldn't to me, be a per-individual-component ACL, but a per-component-type ACL and would be useful. Tim Hare Interested Bystander, Non-Inc. 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 i7L0gOpo014244 for ; Fri, 20 Aug 2004 17:42:24 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 94F9328217B for ; Sat, 21 Aug 2004 02:42:01 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 0DBEF28209E for ; Sat, 21 Aug 2004 02:42:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1CCA0C00F94DD600561A9466@ninevah.local> References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> <1CCA0C00F94DD600561A9466@ninevah.local> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Alternative to splitting out components Date: Sat, 21 Aug 2004 02:42:17 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 00:42:25 -0000 On Aug 21, 2004, at 1:51, Cyrus Daboo wrote: >> - Good multi-author coordination changing different events, or even >> changing different properties of same event --> shared calendars like >> meeting rooms > This is presumably an issue with lock contention when sharing a > calendar? No, not really. I think a WebDAV lock is only good to ensure transaction consistency. If you perform an upload you still need to check whether someone else changed the content which is _far_ more difficult (and time consuming) if the server needs to do it on an arbitary set of events instead of a single one. Also you can't use the already existing WebDAV features (eg if*: headers to ensure that you don't run into issue when doing a PUT on an event). It can be done though (and is implemented in OGo ZideStore). This brings up an issue with PATCH. I'm not sure, but I guess to make PATCH work in this context the server would need to assemble the complete iCalendar file from its database, then apply the PATCH, and then disassemble the patches iCalendar file to database updates? > Do you mean per-component ACLs? i.e. a user has read access to one > component, but not another in the same calendar? I really wonder what > the benefit of that is over just having per-calendar ACLs. Most OpenSource servers (OGo, PHPgroupware, others) actually do only have per-object ACLs. (Kolab is the reverse) Eg in OGo there isn't really something like a single "Calendar", instead you can build arbitary event collections from the database (which in turn honor per-object ACLs). > Certainly in the case of IMAP per-mailbox ACLs are sufficient. The > thought of having per-message ACLs is scary - and I think that boils > down to the user experience - per-message ACLs would really make the > UI too fuzzy in terms of maintaining a clear distinction between what > might be shared or not. I think the same would apply to events in > calendars. No, its not fuzzy at all. Its just a different concept and one which is even gaining popularity in mail applications. There are few mail applications now which do not support query folders (or virtual folders or smart folders, whatever they are called ;-) > My main concern right now is really with the on-the-wire complexity - > I want to keep the requests to a minimum and I think the > one-resource-per-calendar does do that. Can you explain how you see > the on-the-wire-behaviour for doing things like sync'ing an entire > calendar with the current model? Good point. Exchange WebDAV is providing BPROPFIND (and other B=bulk) operations for this. I guess the correct option for CalDAV would be to promote the iCalendar file as a property, so that you can do a: "PROPFIND iCalContent FROM Collection". IMHO: providing a GET to retrieve the full calendar might be a good idea. Nevertheless I want to be able to delete a single event using a DELETE WebDAV call. > (*) There are obviously tradeoffs in the server performance of > single-resource-per-calendar vs single-resource-per-component models - > I am comparing this to the similar case of mailstores that use one > file per-mailbox or one file per-message models. The comparison with mail came up before, I think it is _very_ dangerous to draw this. Mail is an inherently single-user thing, sharing them is the exception (eg IMAP4 doesn't even allow an update operation which can keep object identity) This is different for calendars which are conceptually very focused on sharing. I guess this might be a bit blurred by mail servers like Exchange which where "patched up" to do calendaring as well (and do scheduling by iMIP even though there is a central server ...). It is different for almost any server which was designed for calendaring from the beginning. 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 i7L0Iupo012901 for ; Fri, 20 Aug 2004 17:18:57 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 767A9282131 for ; Sat, 21 Aug 2004 02:18:30 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id E0D5728212E for ; Sat, 21 Aug 2004 02:18:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Alternative to splitting out components Date: Sat, 21 Aug 2004 02:18:46 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Sat, 21 Aug 2004 00:18:58 -0000 Hi Lisa, On Aug 21, 2004, at 0:18, Lisa Dusseault wrote: > A server that supported only one file per calendar doesn't allow > Chandler (or any client) to do the following in very easy/good ways: > - Annotate events with lots of custom properties (I don't consider an > iCalendar file to be a good way to do that for a number of reasons) What do you consider "lots" in this context? 10, 100, 1000 properties? Are any of the properties "big" (KBs or even MBs) or are they more varchar(255) like? Wouldn't x-abc iCalendar properties work for that? This also brings up an interesting question in the per-event model: should dead WebDAV properties get promoted as "x-" iCalendar properties to ensure that the client contains all information for transport? > - Attach conversations to events Can't follow you on that (but I'm very interested in this topic). Does this mean that conversations are stored in a large property? > - Keep very old events around --> keep very large calendars I see no real difference here, this would be a report in your per-item model in any case? If DASL could be used for everything this would be different. > - Good multi-author coordination changing different events, or even > changing different properties of same event --> shared calendars like > meeting rooms Yes, this is the major point. For shared folders processing one iCal file this is much more difficult because the server needs to disassemble the file and do change matching. I'm not sure whether the PATCH extension might help a bit. > - Fast browsing to "what's on this user's calendar today" If you support calculated sequences you need a report for that in any case? No difference. > - Selective permissions > IOW, I think it is in fact simple, but too simplistic. IMHO the major loss is that this "protocol" is losing all the features already specified for WebDAV (that is, for managing collections). Actually I don't even know why this would be called "CalDAV" since it wouldn't reuse any WebDAV features but is regular HTTP GET/PUT? > We could consider another way to accomplish the client simplicity you > propose at the cost of server complexity: require the server to > provide *both* views. Depending on the exact semantics I think this isn't necessarily a lot more work for a server because it needs to deal with iCalendar in any case. PUT is a bit more difficult, but should be reasonable. (OGo already supports both models) > I'm worried that this would require not only more server work but also > have some conflicts that we'd have to figure out how to deal with. > E.g. it doesn't really help multi-author scenarios if the single-file > calendar is always being locked by slow clients. Yes. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: daboo@isamet.com 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 i7KNpnpp011541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2004 16:51:50 -0700 Received: from ninevah.cyrusoft.com (pool-141-151-170-243.pitt.east.verizon.net [141.151.170.243]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7KNZMo3031984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2004 19:35:25 -0400 Date: Fri, 20 Aug 2004 19:51:45 -0400 From: Cyrus Daboo To: Lisa Dusseault Subject: Re: [Ietf-caldav] Alternative to splitting out components Message-ID: <1CCA0C00F94DD600561A9466@ninevah.local> In-Reply-To: References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 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: Fri, 20 Aug 2004 23:51:51 -0000 Hi Lisa, --On Friday, August 20, 2004 3:18 PM -0700 Lisa Dusseault wrote: > A server that supported only one file per calendar doesn't allow > Chandler (or any client) to do the following in very easy/good ways: > - Annotate events with lots of custom properties (I don't consider an > iCalendar file to be a good way to do that for a number of reasons) Are you assuming that users won't want to include such annotations if they use some other way of transporting the component (e.g. iMIP)? > - Attach conversations to events What are 'conversations' in this context? > - Keep very old events around --> keep very large calendars Large calendars would not be a problem (* see below for a comment on this): in theory it would be possible for a caldav server to disable GET and PUT on the calendar file resource and only allow PROPFIND, REPORT and PATCH as the means to access and change components. That would force the client (authors) to think about exactly what they want and only ask for that. > - Good multi-author coordination changing different events, or even > changing different properties of same event --> shared calendars like > meeting rooms This is presumably an issue with lock contention when sharing a calendar? > - Fast browsing to "what's on this user's calendar today" A report can easily handle that for either model. > - Selective permissions Do you mean per-component ACLs? i.e. a user has read access to one component, but not another in the same calendar? I really wonder what the benefit of that is over just having per-calendar ACLs. Certainly in the case of IMAP per-mailbox ACLs are sufficient. The thought of having per-message ACLs is scary - and I think that boils down to the user experience - per-message ACLs would really make the UI too fuzzy in terms of maintaining a clear distinction between what might be shared or not. I think the same would apply to events in calendars. > IOW, I think it is in fact simple, but too simplistic. >> We could consider another way to accomplish the client simplicity you > propose at the cost of server complexity: require the server to provide > *both* views. I'm worried that this would require not only more server > work but also have some conflicts that we'd have to figure out how to > deal with. E.g. it doesn't really help multi-author scenarios if the > single-file calendar is always being locked by slow clients. I think that is pretty much what I proposed before with the Level 1/Level 2 type behaviour, but now think Level 2 is too complex. My main concern right now is really with the on-the-wire complexity - I want to keep the requests to a minimum and I think the one-resource-per-calendar does do that. Can you explain how you see the on-the-wire-behaviour for doing things like sync'ing an entire calendar with the current model? (*) There are obviously tradeoffs in the server performance of single-resource-per-calendar vs single-resource-per-component models - I am comparing this to the similar case of mailstores that use one file per-mailbox or one file per-message models. Some operations perform better in each of the different models. Also things like backup/restore perform better for the per-message as opposed to per-mailbox model. But that level of detail in server implementation should not be a consideration. -- Cyrus Daboo X-Envelope-From: elias@cse.ucsc.edu X-Envelope-To: Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7KNKTpo009879 for ; Fri, 20 Aug 2004 16:20:29 -0700 Received: from cse.ucsc.edu (adsl-63-194-88-161.dsl.snfc21.pacbell.net [63.194.88.161]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id i7KNKMNW012869 for ; Fri, 20 Aug 2004 19:20:22 -0400 Message-ID: <412686CD.60800@cse.ucsc.edu> Date: Fri, 20 Aug 2004 16:18:37 -0700 From: Elias Sinderson User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] Alternative to splitting out components References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-caldav@osafoundation.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2004 23:20:31 -0000 Lisa Dusseault wrote: > We could consider another way to accomplish the client simplicity you > propose at the cost of server complexity: require the server to > provide *both* views. I'm worried that this would require not only > more server work but also have some conflicts that we'd have to figure > out how to deal with. E.g. it doesn't really help multi-author > scenarios if the single-file calendar is always being locked by slow > clients. More work, yes, but not really all that much when you think about it. One option would be to have the specification define (as a MUST) a property, P, on component resources whose value is an XML marshalling of the components content and properties. A live property on the main calendar resource would then simply scoop up all the child components values of P and then return a single XML document. Leave it up to the server implementors as to how they implement P, as long as they return a conformant piece of XML when queried. P may be live (and either computed dynamically every time or cached), or dead and set by the server when a component is created or modified. It may take a bit for a client to get the whole calendar back, but when asking for an entire calendar perhaps that should be expected. Further, the performance hit that a client will take when using this simpler approach will create a competitive edge in implementing a better client. ;-) Cheers, Elias X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7KMItpp005978 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 20 Aug 2004 15:19:01 -0700 In-Reply-To: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> References: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Alternative to splitting out components Date: Fri, 20 Aug 2004 15:18:48 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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: Fri, 20 Aug 2004 22:19:03 -0000 OSAF looked at this model initially for Chandler, because it's one of the models out there in the wild and would provide some interoperability. But it didn't quite meet our requirements for core Chandler features. A server that supported only one file per calendar doesn't allow Chandler (or any client) to do the following in very easy/good ways: - Annotate events with lots of custom properties (I don't consider an iCalendar file to be a good way to do that for a number of reasons) - Attach conversations to events - Keep very old events around --> keep very large calendars - Good multi-author coordination changing different events, or even changing different properties of same event --> shared calendars like meeting rooms - Fast browsing to "what's on this user's calendar today" - Selective permissions IOW, I think it is in fact simple, but too simplistic. We could consider another way to accomplish the client simplicity you propose at the cost of server complexity: require the server to provide *both* views. I'm worried that this would require not only more server work but also have some conflicts that we'd have to figure out how to deal with. E.g. it doesn't really help multi-author scenarios if the single-file calendar is always being locked by slow clients. Lisa On Aug 20, 2004, at 1:57 PM, Cyrus Daboo wrote: > Hi folks, > I would like to propose an alternative model to the one currently > specified in Lisa's draft. Specifically I would like to not have each > individual component in an iCalendar object split out into its own > WebDAV resource on the server. i.e. we would only deal with entire > iCalendar files as WebDAV resources. > > There are several reasons why I would prefer this approach: > > - There is a significant added complexity in having each component be > a separate resource. Clients will have to maintain the uris, etags etc > for each component in addition to all the usual iCalendar data. > Reports (e.g. 'time-range-events' example in the draft) from the > server will have to include the uri for each component resource that > is returned, which means that the response to such a report will > likely have to be XML, rather than a simple iCalendar object with the > matching components etc. Updating multiple components requires > separate HTTP requests for each resource, so large changes to a > calendar (e.g. disconnected sync operations) can be expensive. > > - By keeping the iCalendar data in one file, we gain the benefit that > existing http and webdav clients can use PUT/GET etc operations to get > the calendar in the way that a lot of clients do already - i.e. > existing http/webdav clients would interoperate. > > We would still have reports (such as those already in the draft) for > getting component ranges for efficient (selective) component > downloads. However we would need a way to do selective changes to to > components in the single iCalendar resource. I would propose using > Lisa's HTTP PATCH extension > -04.txt> as the solution to that, with a special application/caldiff > patch format that we define to allow addressing of individual iCal > components. The patch format would allow multiple components to be > changed in a single request. > > Comments? > > -- > Cyrus Daboo > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 i7KKvSpp001564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2004 13:57:29 -0700 Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i7KKf3o3028997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2004 16:41:05 -0400 Date: Fri, 20 Aug 2004 16:57:26 -0400 From: Cyrus Daboo To: ietf-caldav@osafoundation.org Message-ID: <86D39D5AD46C01B60617E02C@ninevah.cyrusoft.com> X-Mailer: Mulberry/4.0.0d1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Scanned-By: MIMEDefang 2.39 X-Mailman-Approved-At: Fri, 20 Aug 2004 14:08:49 -0700 Subject: [Ietf-caldav] Alternative to splitting out components 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, 20 Aug 2004 20:57:30 -0000 Hi folks, I would like to propose an alternative model to the one currently specified in Lisa's draft. Specifically I would like to not have each individual component in an iCalendar object split out into its own WebDAV resource on the server. i.e. we would only deal with entire iCalendar files as WebDAV resources. There are several reasons why I would prefer this approach: - There is a significant added complexity in having each component be a separate resource. Clients will have to maintain the uris, etags etc for each component in addition to all the usual iCalendar data. Reports (e.g. 'time-range-events' example in the draft) from the server will have to include the uri for each component resource that is returned, which means that the response to such a report will likely have to be XML, rather than a simple iCalendar object with the matching components etc. Updating multiple components requires separate HTTP requests for each resource, so large changes to a calendar (e.g. disconnected sync operations) can be expensive. - By keeping the iCalendar data in one file, we gain the benefit that existing http and webdav clients can use PUT/GET etc operations to get the calendar in the way that a lot of clients do already - i.e. existing http/webdav clients would interoperate. We would still have reports (such as those already in the draft) for getting component ranges for efficient (selective) component downloads. However we would need a way to do selective changes to to components in the single iCalendar resource. I would propose using Lisa's HTTP PATCH extension as the solution to that, with a special application/caldiff patch format that we define to allow addressing of individual iCal components. The patch format would allow multiple components to be changed in a single request. Comments? -- 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 i7IKrkpo030037 for ; Wed, 18 Aug 2004 13:53:47 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 2CB3528185A for ; Wed, 18 Aug 2004 22:53:37 +0200 (CEST) Received: from [192.168.102.125] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id CC44728178E for ; Wed, 18 Aug 2004 22:53:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: CalDAV DevList From: Helge Hess Date: Wed, 18 Aug 2004 22:53:35 +0200 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] CalDAV Notes 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, 18 Aug 2004 20:53:48 -0000 Hi, some notes on the CalDAV draft from my OGo-centric POV. Note that those are just "rough" impressions I got from reading over it. Please feel free to clarify or comment. ACL === - do we need this for minimum compliance? - we already discussed this a bit and I made the suggestion of using a capability for this (Dan correctly points out that too many options will be annoying for client authors) - a lot of OpenSource servers do not have real "calendar" collections (OGo is in this category) - so "calendars" are just queries and you cannot usually define an ACLs on it - some servers which have "calendar" collections may not have per object ACLs (eg Kolab falls into this category) Custom Props (dead props) ========================= - not all servers are flexible enough to allow for this or may be slow for custom props if they allow for them (eg OGo uses a separate SQL table for custom properties) - but they might be worth it Fanout ====== - hm, not entirely sure about this and how a client would use it - sounds like the server needs to be quite clever for that and implement a lot of things - maybe Dan can say something about this, how would Evolution use this feature? Recurrance ========== - there is already a discussion going on about that - OGo at least does not support "calculated" cycles, if there is an iCal PUT of a vevent with recurrence, OGo expands the recurrence and creates individual (but connected) events (which is IMHO correct for almost all but a few cases) - so a client is required to update after performing a PUT because a PUT could result into collection changes - yes, we might support calculated cycles, but this is additional work - maybe CalDAV could consider the way OGo works (and I think several other servers) and have some support for that? More exactly this would require some "DELETE-COMPLETE-CYCLE" method in addition to "DELETE". - I understand that this might be too specific Notifications (/ Polling) ============= - we already discussed this, I think we more or less agreed that for basic CalDAV we can use etags and for advanced CalDAV we should use some Jabber based protocol Collections =========== - you specify collection types as a complex XML property, eg: I "predict" that this will give issues ;-) because a lot of servers will map properties to simple key/stringvalue hashtables (eg resourcetype=collection) (although of course XML content is valid in WebDAV properties, I think few are actually prepared for this) - this seems to be quite deeply nested? - I have not understood the motivation behind the "Calendar Container" collection. "can automatically detect when a user has multiple calendars" - isn't that done by browsing the collection hierarchy? - "Calendars MUST NOT contain other calendars" - hm, why? I think this breaks the common Outlook model also uses in Evolution where you can nest object folders arbitary - multiple Event collections inside a Calendar collection - can't we drop that and move all Events up into the Calendar collection? - "substructure can be used to organize" - do we need collections here? Maybe a DASL query on some type is better? - todo as subcollection of calendar - this matches the Apple iCal, Mozilla and KOrganizer UI - it doesn't match Outlook/Evolution (and OGo WebUI ;-) - personally I prefer having them separate because there is no real association them in the real world? Dan, whats your opinion on this? Timezones ========= - well, I would prefer to have everything in UTC - yes, I understood that the timezone is required for recurrences ;-) - "The default calendar timezone is probably simply a property value on the calendar collection, which the calendaring client can change." - this sounds like it would be problematic for shared calendars? - if we store the timezone, it belongs to the event, not to the calendar (since the calendar timezone can be changed), right? - as mentioned in the list, a simple rule as required for recurrences would be preferred over full timezone support (eg all ranges which require offsets) - Sidenote: OGo stores everything in UTC, it provides full timezone support but does not support "calculated" cycles, so we don't run into these issues Extension ========= 'For optimum interoperability with existing HTTP clients, CalDAV clients and servers MUST use the file extension ".ics"' - does this really provide benefits in practice? I understand the motiviation, but I guess no one will ever use this in practice (like no one mounts an Exchange collection as a WebFolder to access items ...) Properties ========== 'Thus, a server MAY canonicalize its resource bodies (e.g. eliminate meaningless spaces) but MUST preserve all data' - since most servers will not store the iCal itself but dynamically convert to their internal representation, this will be problematic - basically the same issue like "dead properties" - "REQUIRED properties for promotion from iCalendar" - could some point me to why dtstart/dtend _and_ duration are required? Reports ======= - this sounds like putting complex method calls on top of WebDAV, which I do no really like - we could use XML-RPC or SOAP for that? - time ranges are covered by DASL - options could be either a header (like "expand-recurrence: true") or a special dynamic subcollection (lisa/Calendar/expanded/) - a header is bad because it affects HTTP style caching - "12.1.1 Request for 'calendar-time-range'" Sample request for 'time-range-events' report ... Isn't that a simple DASL query?: SELECT dtstart, dtend, sumary, valarm FROM /lisa/Calendar/ WHERE dtstart<20041131 AND dtend>20031101 AND type=vevent; No need for a custom report? Disconnected ============ - AFAIK Exchange has "folder versions" (the folder version property changes if any content item is changed) - pretty expensive to implement in server with "dynamic" servers like OGo - already had a discussion on this in the POLL context ;-) OK, thats it. Please note that those are really just notes and might not be well though out ;-) but nevertheless I would appreciate feedback on those items. best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7IH1ipp007767 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 18 Aug 2004 10:01:46 -0700 In-Reply-To: <1092838145.27786.313.camel@twelve-monkeys.boston.ximian.com> References: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> <1092838145.27786.313.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <435BA4E6-F138-11D8-A54B-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] polling Date: Wed, 18 Aug 2004 10:01:35 -0700 To: Dan Winship X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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: Wed, 18 Aug 2004 17:01:47 -0000 I think Dan's right, in that the problems with timestamps can be resolved if everything is determined by the server's timestamp. The server has a responsibility to keep a consistent clock, where time moves forward and not backwards. The server provides Last-Modified headers already for resources. The server must respond to any HTTP request with the Date: header so the client always knows what the server considered the time to be, when the last request was made. So all the client has to do is remember the server's timestamp when it last synchronized, and ask the server for changes since that timestamp. But this all only applies to a theoretical feature to make synchronization perform better -- synchronization is already quite possible with ETags, albeit not as efficient as it might be. I don't consider high-perf synchronization to be a requirement for base CalDAV. That would alleviate the concern that this materially changes the data model for CalDAV from the current WebDAV model. Lisa On Aug 18, 2004, at 7:09 AM, Dan Winship wrote: > On Tue, 2004-08-17 at 23:32 +0200, Helge Hess wrote: >> modtime >> ======= >> This simply can't work?! You cannot base a synchronisation decision on >> a modification time which is kept in a 1s or less granularity. > > I used 1-minute granularity in the example because I didn't want to > write out longer timestamps. :-) I was assuming they would in reality > be > much more granular than that. > >> In addition modtimes are broken because they require the client and >> server to be in sync. > > Not really. The poll response just needs to include the current server > time, and the client remembers that value until the next time it polls. > (It doesn't even need to be in a form that the client can parse. It > could be specified as just an opaque cookie of some sort.) > >> Servers >> ======= >> You expect servers to change the data model for CalDAV. This won't >> make >> people happy ;-) > > You expect to be able to be able to support the Next Great Thing > without > changing any code? :-) > >> So back to server vs client, to solve (changes marked with _): >> "make it possible for a client to find out about all modifications to, >> additions to, and deletions from a collection since _the last sync_, > > Well... I suppose that's actually what I meant. > >> , _and without requiring any changes on servers_". > > "Besides that they support CalDAV" :) > >> IMHO this is well covered by both, iCalendar and WebDAV. The client >> needs to manage a snapshot of the last sync with its cache to ensure >> its validity. Doing this is pretty trivial, either: >> a) select the uid + iCal sequence >> orAt any rate >> b) select the resource + etag > > Well, sure, this is what the Evo Exchange Connector does now, but it > sucks if you have a huge calendar, because it has to pull the complete > list of UIDs over the network every time. > > > FWIW, a completely modtime-unaware server could implement the poll > report like this: > > 4 objects in collection > > Modified/Added uids: > 306A > 9294 > 53A1 > 99BB > > Removed objects before: > seq 1, uid 306A > seq 2, uid 9294 > seq 3, uid 53A1 > seq 4, uid 99BB > > ie, ignore the client-provided timestamp entirely and just send the > complete list of objects in the response. The modified/added part would > force the client to re-fetch every object, and the removed part would > force it to discard any object that wasn't in that list, and you'd end > up synced, just not as efficiently as in the case where the server was > keeping track of the extra info. (By adding etags or whatever to the > first part, we could also let the client avoid re-fetching any objects > that hadn't actually changed from its cache.) > > -- Dan > > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 i7IGIwpo004490 for ; Wed, 18 Aug 2004 09:18:59 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CBED227E3C3; Wed, 18 Aug 2004 18:18:47 +0200 (CEST) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 798C027DE0B; Wed, 18 Aug 2004 18:18:47 +0200 (CEST) In-Reply-To: <1092838145.27786.313.camel@twelve-monkeys.boston.ximian.com> References: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> <1092838145.27786.313.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4C6E12F8-F132-11D8-8F23-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] polling Date: Wed, 18 Aug 2004 18:18:54 +0200 To: Dan Winship X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Wed, 18 Aug 2004 16:19:00 -0000 On Aug 18, 2004, at 16:09, Dan Winship wrote: > On Tue, 2004-08-17 at 23:32 +0200, Helge Hess wrote: >> modtime >> ======= >> This simply can't work?! You cannot base a synchronisation decision on >> a modification time which is kept in a 1s or less granularity. > I used 1-minute granularity in the example because I didn't want to > write out longer timestamps. :-) I was assuming they would in reality > be > much more granular than that. As mentioned even one second granularity is _far_ from being enough. And I think we can safely assume that this is the max provided by current servers (being often based on utime). >> In addition modtimes are broken because they require the client and >> server to be in sync. > Not really. The poll response just needs to include the current server > time, and the client remembers that value until the next time it polls. > (It doesn't even need to be in a form that the client can parse. It > could be specified as just an opaque cookie of some sort.) True. >> You expect servers to change the data model for CalDAV. This won't >> make >> people happy ;-) > You expect to be able to be able to support the Next Great Thing > without > changing any code? :-) Yes. This is the Next Great Thing because it makes stuff interoperate, not because it adds great new features. Lets make that step 2 ;-) >> So back to server vs client, to solve (changes marked with _): >> "make it possible for a client to find out about all modifications to, >> additions to, and deletions from a collection since _the last sync_, > Well... I suppose that's actually what I meant. OK. >> , _and without requiring any changes on servers_". > "Besides that they support CalDAV" :) Yes ;-) >> IMHO this is well covered by both, iCalendar and WebDAV. The client >> needs to manage a snapshot of the last sync with its cache to ensure >> its validity. Doing this is pretty trivial, either: >> a) select the uid + iCal sequence >> orAt any rate >> b) select the resource + etag > Well, sure, this is what the Evo Exchange Connector does now, but it > sucks if you have a huge calendar, because it has to pull the complete > list of UIDs over the network every time. OK. What do you consider a big calendar? A uid ~16 bytes + a sequence ~4 bytes makes 20 bytes per event. This is raw 200KB for 10.000 events which can be certainly considered a pretty big calendar folder. This 200KB can be easily compressed (gzip transfer encoding is trivial to implement) to 25KB in practice. I consider this reasonable. Note: Level X servers can still opt to provide reliable notifications. The client could reduce the poll rate if the server supports this. Suitable compromise? > FWIW, a completely modtime-unaware server could implement the poll > report like this: I think that we can safely assume that all servers support modification time data. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7IE76pp026256 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 18 Aug 2004 07:07:07 -0700 Received: (qmail 12581 invoked from network); 18 Aug 2004 14:07:00 -0000 Received: from outbound.ximian.com (HELO twelve-monkeys.boston.ximian.com) (130.57.170.250) by peabody.ximian.com with SMTP; 18 Aug 2004 14:07:00 -0000 Subject: Re: [Ietf-caldav] polling From: Dan Winship To: Helge Hess In-Reply-To: References: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain Date: Wed, 18 Aug 2004 10:09:05 -0400 Message-Id: <1092838145.27786.313.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.92 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 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: Wed, 18 Aug 2004 14:07:08 -0000 On Tue, 2004-08-17 at 23:32 +0200, Helge Hess wrote: > modtime > ======= > This simply can't work?! You cannot base a synchronisation decision on > a modification time which is kept in a 1s or less granularity. I used 1-minute granularity in the example because I didn't want to write out longer timestamps. :-) I was assuming they would in reality be much more granular than that. > In addition modtimes are broken because they require the client and > server to be in sync. Not really. The poll response just needs to include the current server time, and the client remembers that value until the next time it polls. (It doesn't even need to be in a form that the client can parse. It could be specified as just an opaque cookie of some sort.) > Servers > ======= > You expect servers to change the data model for CalDAV. This won't make > people happy ;-) You expect to be able to be able to support the Next Great Thing without changing any code? :-) > So back to server vs client, to solve (changes marked with _): > "make it possible for a client to find out about all modifications to, > additions to, and deletions from a collection since _the last sync_, Well... I suppose that's actually what I meant. > , _and without requiring any changes on servers_". "Besides that they support CalDAV" :) > IMHO this is well covered by both, iCalendar and WebDAV. The client > needs to manage a snapshot of the last sync with its cache to ensure > its validity. Doing this is pretty trivial, either: > a) select the uid + iCal sequence > orAt any rate > b) select the resource + etag Well, sure, this is what the Evo Exchange Connector does now, but it sucks if you have a huge calendar, because it has to pull the complete list of UIDs over the network every time. FWIW, a completely modtime-unaware server could implement the poll report like this: 4 objects in collection Modified/Added uids: 306A 9294 53A1 99BB Removed objects before: seq 1, uid 306A seq 2, uid 9294 seq 3, uid 53A1 seq 4, uid 99BB ie, ignore the client-provided timestamp entirely and just send the complete list of objects in the response. The modified/added part would force the client to re-fetch every object, and the removed part would force it to discard any object that wasn't in that list, and you'd end up synced, just not as efficiently as in the case where the server was keeping track of the extra info. (By adding etags or whatever to the first part, we could also let the client avoid re-fetching any objects that hadn't actually changed from its cache.) -- Dan 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 i7IC5Xpo016144 for ; Wed, 18 Aug 2004 05:05:34 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 675ED2814B5; Wed, 18 Aug 2004 14:05:21 +0200 (CEST) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id E444B27E8E9; Wed, 18 Aug 2004 14:05:20 +0200 (CEST) In-Reply-To: <6.1.1.1.0.20040817224733.027c5cf0@mail.comcast.net> References: <1EC7850C-F07C-11D8-AB59-000A95B2BB72@osafoundation.org> <500A2AA2-F091-11D8-8F23-000D93C1A604@opengroupware.org> <109601c484ab$2bfe32d0$200ca8c0@wkearney.com> <6.1.1.1.0.20040817224733.027c5cf0@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Re: RSS for calendar exchange /polling / etc. Date: Wed, 18 Aug 2004 14:05:28 +0200 To: TimHare@comcast.net X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Wed, 18 Aug 2004 12:05:35 -0000 On Aug 18, 2004, at 5:01, TimHare@comcast.net wrote: > I think the tombstone idea is pretty do-able; I don't know the length > of the UID, but assuming a 20 bye UID and a 4 byte binary timestamp to > track when it was deleted we could store an awful lot of tombstones. As mentioned before this also has the two issues: a) timestamps are not suitable (please: correct me if I'm wrong) b) you need functional changes to server storage (for tracking the deletion) I agree that the storage amount should not be a problem, though you need to consider scale (eg 60000 users x 100 changes per week ...). In addition bad synchronization software could create excessive amounts of changes (eg by implementing changes as read, delete, write - eg a Kolab connector would have this problem). Anyway, I think OGo could live with implementing tombstones (though I'm still not convinced that this is necessary, see my other mail). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: TimHare@comcast.net X-Envelope-To: 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 i7I37bpo008210 for ; Tue, 17 Aug 2004 20:07:37 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (rwcrmhc13) with SMTP id <2004081803072901500sete4e> (Authid: TimHare); Wed, 18 Aug 2004 03:07:29 +0000 Message-Id: <6.1.1.1.0.20040817224733.027c5cf0@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Tue, 17 Aug 2004 23:01:28 -0400 To: ietf-caldav@osafoundation.org From: TimHare@comcast.net In-Reply-To: <109601c484ab$2bfe32d0$200ca8c0@wkearney.com> References: <1EC7850C-F07C-11D8-AB59-000A95B2BB72@osafoundation.org> <500A2AA2-F091-11D8-8F23-000D93C1A604@opengroupware.org> <109601c484ab$2bfe32d0$200ca8c0@wkearney.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Re: RSS for calendar exchange /polling / etc. 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, 18 Aug 2004 03:07:38 -0000 As I understand RSS readers, RSS is essentially a polling operation: check for updates to the feed every so often = polling in my book. I think the tombstone idea is pretty do-able; I don't know the length of the UID, but assuming a 20 bye UID and a 4 byte binary timestamp to track when it was deleted we could store an awful lot of tombstones. I don't think Calendar items/changes reach the volume of e-mail items in a comparable IMAP system. I don't have statistics, if anyone does please share them, but a rough guess of what happens at work is that the number of Calendar invitations/changes I receive per day is an order of magnitude smaller than the number of e-mail messages. Here's possibly a compromise idea? (again remembering that I haven't completely read the DAV spec). A client that wants to only check once in a while does nothing. A client that wants to be more up-to-date sends a subscription request, for lack of a better term, naming the collection, to the server. When there are updates to a collection, the server sends a notification message to the subscribers, who then check for the updates. This keeps total message volume down: some clients check when they want, which hopefully is not super-frequent; those that need notification get a short fast message telling them when to do the more complex work of looking for the changes. Tim Hare, Interested Bystander, Non-Inc. X-Envelope-From: wkearney@syndic8.com X-Envelope-To: Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7HMeJpp023677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Aug 2004 15:40:19 -0700 Received: (qmail 13470 invoked from network); 17 Aug 2004 22:40:18 -0000 Received: from xbox.wkearney.com (HELO media) ([66.92.145.79]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Aug 2004 22:40:18 -0000 Message-ID: <109601c484ab$2bfe32d0$200ca8c0@wkearney.com> From: "Bill Kearney" Cc: References: <1EC7850C-F07C-11D8-AB59-000A95B2BB72@osafoundation.org> <500A2AA2-F091-11D8-8F23-000D93C1A604@opengroupware.org> Subject: Re: [Ietf-caldav] Fwd: [Dev] RSS for calendar exchange?! Date: Tue, 17 Aug 2004 18:40:13 -0400 Organization: http://www.ideaspace.net/users/wkearney/foaf.xrdf MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Scanned-By: MIMEDefang 2.39 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, 17 Aug 2004 22:40:20 -0000 > The problem with RSS is that there are too many applications for it ;-) > Eg I can think of at least 20 different things which OGo could export > as RSS feeds and a lot of them are per-object (eg a separate task RSS > for each project). And handling so many different feeds with semantic > value again requires a pretty powerful RSS reader (more than the usual > display some news thing). Bear in mind that an arms race, figuratively speaking, in RSS readers would depend on there being more robust content available. Publishing calendar data in 'native forms' as opposed to 'pretty printed' into HTML descriptions could go a long way toward jumpstarting the competition in this field. The readers already have a certain degree of 'lead time' in the race as they've already tackled a good bit of the UI side of the application. So it's entirely reasonable to use something like an RSS-1.0 formatted feed for this purpose. You can publish the parts that existing RSS readers can use while also piggy-backing along the live data. The readers that don't know how to use it won't be 'harmed'. Then it's just a matter of picking among the many readers to decide who to encourage developing support for your additions. -Bill Kearney Syndic8.com 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 i7HLWQpo017796 for ; Tue, 17 Aug 2004 14:32:27 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id F1606281D7A; Tue, 17 Aug 2004 23:32:19 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 8A8A7281D6B; Tue, 17 Aug 2004 23:32:19 +0200 (CEST) In-Reply-To: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> References: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] polling Date: Tue, 17 Aug 2004 23:32:21 +0200 To: Dan Winship X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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, 17 Aug 2004 21:32:28 -0000 On Aug 17, 2004, at 18:33, Dan Winship wrote: > (The exact problem that the following protocol is trying to solve is > "make it possible for a client to find out about all modifications to, > additions to, and deletions from a collection since an arbitrary time > in > the past, without requiring the server to keep an unbounded amount of > historical data or per-client state".) OK, read the approach, clever idea! :-) I have some issues with that though (well, actually I notice that this is indeed some kind of server author vs client author thing as well ;-): modtime ======= This simply can't work?! You cannot base a synchronisation decision on a modification time which is kept in a 1s or less granularity. If only two people do a Palm sync to a shared folder in some overlapping time (9:00 AM at the office) this is bound to break (given that we can handle at least something between 10-100 changes per second). In addition modtimes are broken because they require the client and server to be in sync. Servers ======= You expect servers to change the data model for CalDAV. This won't make people happy ;-) If this really needs to be done at the server, I prefer to have a different service for that. Actually I think this is what SyncML might already cover (with per client state though). So back to server vs client, to solve (changes marked with _): "make it possible for a client to find out about all modifications to, additions to, and deletions from a collection since _the last sync_, without requiring the _client_ to keep an unbounded amount of historical data or per-client state, _and without requiring any changes on servers_". IMHO this is well covered by both, iCalendar and WebDAV. The client needs to manage a snapshot of the last sync with its cache to ensure its validity. Doing this is pretty trivial, either: a) select the uid + iCal sequence or b) select the resource + etag I think tracking server changes this way is really reasonable for client authors (just keep the hrefs/etags the cache is based on with the cache). Compatibility with servers which cannot track an object version is also easy to solve. They can simply use the moddate timestamp (utime or seconds since 2000 or whatever) as the version, this will give them the maximum possible granularity in this setup. Hm, did I miss something? ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: helge.hess@opengroupware.org 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 i7HL6bpo016538; Tue, 17 Aug 2004 14:06:37 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id DD437281D53; Tue, 17 Aug 2004 23:06:29 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 73F80281D44; Tue, 17 Aug 2004 23:06:29 +0200 (CEST) In-Reply-To: <1EC7850C-F07C-11D8-AB59-000A95B2BB72@osafoundation.org> References: <1EC7850C-F07C-11D8-AB59-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <500A2AA2-F091-11D8-8F23-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Fwd: [Dev] RSS for calendar exchange?! Date: Tue, 17 Aug 2004 23:06:31 +0200 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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, 17 Aug 2004 21:06:38 -0000 On Aug 17, 2004, at 20:34, Lisa Dusseault wrote: > This kind of thing might work together well with CalDAV -- a server or > a client could be responsible for creating these to reflect the > content in a CalDAV calendar. This isn't something we'd want to make > required in CalDAV from the outset, but it's certainly nice to keep in > mind. Actually the OGo ZideStore servers supports RSS on task folders, I don't think that someone uses that in practice though. The problem with RSS is that there are too many applications for it ;-) Eg I can think of at least 20 different things which OGo could export as RSS feeds and a lot of them are per-object (eg a separate task RSS for each project). And handling so many different feeds with semantic value again requires a pretty powerful RSS reader (more than the usual display some news thing). Anyway, I don't think this is really related to CalDAV. I think RSS is more to be seen as a "display" format, like HTML, while CalDAV is more about exact storage. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 i7HImOpp009463 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 Aug 2004 11:48:25 -0700 In-Reply-To: <1092768107.27783.131.camel@twelve-monkeys.boston.ximian.com> References: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> <805638E3-F06F-11D8-AB59-000A95B2BB72@osafoundation.org> <1092768107.27783.131.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <00878F68-F07E-11D8-AB59-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] polling Date: Tue, 17 Aug 2004 11:48:17 -0700 To: Dan Winship X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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, 17 Aug 2004 18:48:26 -0000 Yes, as you say, the server could define some period beyond which it's not willing to keep replication/synchronization data (tombstones, new items and other change information -- all of which might require special storage anyway in order to perform quickly. ) For example, lets say that the server keeps such data for a week. Then any client that synchronizes daily is well under the limit. What if you're over the limit and haven't synchronized in over a week? Well it's still possible to synchronize without this REPORT, it just takes more requests and more client parsing. Storage space is so cheap however, this could easily be one of those decisions where space is sacrificed in order to achieve greater performance/scalability. Lisa On Aug 17, 2004, at 11:41 AM, Dan Winship wrote: > On Tue, 2004-08-17 at 10:04 -0700, Lisa Dusseault wrote: >> There's another way to track deleted items, which is tombstones, which >> I prefer to IMAP-style sequence numbers. You'd give everything UIDs, >> as in your scheme, and mark some UIDs as deleted since timestamp T. I >> believe tombstones are much easier to track for both client and server >> in many situations, because each item has fewer dependencies on other >> items. > > I agree that that's simpler, but you'd need to keep the tombstone > around > forever, right? So the amount of storage space used by the collection > is > proportional to the total number of items that have ever been in it. Or > alternatively, if you do garbage-collect the tombstones after a while, > then there's an upper limit on how long the client can go between > connections and still be able to incrementally resync afterwards. > Whereas with my suggestion, the total storage space used stays > proportional to the current size of the collection, and the client can > resync at any time and only need to download an amount of data > proportional to the number of changes made since the last sync. > > -- Dan > > X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7HIdtpp008828 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 17 Aug 2004 11:39:56 -0700 Received: (qmail 10610 invoked from network); 17 Aug 2004 18:39:48 -0000 Received: from outbound.ximian.com (HELO twelve-monkeys.boston.ximian.com) (130.57.170.250) by peabody.ximian.com with SMTP; 17 Aug 2004 18:39:48 -0000 Subject: Re: [Ietf-caldav] polling From: Dan Winship To: Lisa Dusseault In-Reply-To: <805638E3-F06F-11D8-AB59-000A95B2BB72@osafoundation.org> References: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> <805638E3-F06F-11D8-AB59-000A95B2BB72@osafoundation.org> Content-Type: text/plain Date: Tue, 17 Aug 2004 14:41:46 -0400 Message-Id: <1092768107.27783.131.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.92 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 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, 17 Aug 2004 18:39:56 -0000 On Tue, 2004-08-17 at 10:04 -0700, Lisa Dusseault wrote: > There's another way to track deleted items, which is tombstones, which > I prefer to IMAP-style sequence numbers. You'd give everything UIDs, > as in your scheme, and mark some UIDs as deleted since timestamp T. I > believe tombstones are much easier to track for both client and server > in many situations, because each item has fewer dependencies on other > items. I agree that that's simpler, but you'd need to keep the tombstone around forever, right? So the amount of storage space used by the collection is proportional to the total number of items that have ever been in it. Or alternatively, if you do garbage-collect the tombstones after a while, then there's an upper limit on how long the client can go between connections and still be able to incrementally resync afterwards. Whereas with my suggestion, the total storage space used stays proportional to the current size of the collection, and the client can resync at any time and only need to download an amount of data proportional to the number of changes made since the last sync. -- Dan X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7HIYupp008526 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 17 Aug 2004 11:34:58 -0700 Mime-Version: 1.0 (Apple Message framework v618) To: ietf-caldav@osafoundation.org Message-Id: <1EC7850C-F07C-11D8-AB59-000A95B2BB72@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-13-643855752 From: Lisa Dusseault Date: Tue, 17 Aug 2004 11:34:49 -0700 X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] Fwd: [Dev] RSS for calendar exchange?! 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, 17 Aug 2004 18:34:59 -0000 --Apple-Mail-13-643855752 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This kind of thing might work together well with CalDAV -- a server or a client could be responsible for creating these to reflect the content in a CalDAV calendar. This isn't something we'd want to make required in CalDAV from the outset, but it's certainly nice to keep in mind. For those who don't know, the AtomPub WG is actually bringing syndication formats to the IETF for real open standardization. Lisa Begin forwarded message: > From: Ted Leung > Date: August 17, 2004 10:53:08 AM PDT > To: OSAF Development > Subject: [Dev] RSS for calendar exchange?! > > I stumbled across this article yesterday... > > http://news.com.com/RSS+gets+down+to+business/2100-1012_3 > -5311747.html?part=rss&tag=5311747&subj=news.1012.5 > > ---- > Ted Leung Open Source Applications Foundation (OSAF) > PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42 > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > Open Source Applications Foundation "Dev" mailing list > http://lists.osafoundation.org/mailman/listinfo/dev --Apple-Mail-13-643855752 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII This kind of thing might work together well with CalDAV -- a server or a client could be responsible for creating these to reflect the content in a CalDAV calendar. This isn't something we'd want to make required in CalDAV from the outset, but it's certainly nice to keep in mind. For those who don't know, the AtomPub WG is actually bringing syndication formats to the IETF for real open standardization. Lisa Begin forwarded message: 0000,0000,0000From: Ted Leung < 0000,0000,0000Date: August 17, 2004 10:53:08 AM PDT 0000,0000,0000To: OSAF Development < 0000,0000,0000Subject: [Dev] RSS for calendar exchange?! I stumbled across this article yesterday... http://news.com.com/RSS+gets+down+to+business/2100-1012_3-5311747.html?part=rss&tag=5311747&subj=news.1012.5 ---- Ted Leung Open Source Applications Foundation (OSAF) PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev --Apple-Mail-13-643855752-- 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 i7HHLxpp004992 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 Aug 2004 10:21:59 -0700 In-Reply-To: <6.1.1.1.0.20040816202841.02832180@mail.comcast.net> References: <6.1.1.1.0.20040816202841.02832180@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Tue, 17 Aug 2004 10:21:51 -0700 To: TimHare@comcast.net X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: [Ietf-calsify] Calsify list vs. CalDAV list? 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, 17 Aug 2004 17:22:01 -0000 That wasn't what I was trying to convey, I'm sorry if I wasn't clear enough about the purpose of the two lists. The purpose of CALSIFY is only to revise the iCalendar, and possibly iMIP and iTIP RFCs, to go to draft standard, if that can be done and can improve interoperability and deployment. Since you can't add features when going to draft standard, clearly any "server" feature, including notifications, is out of scope for CALSIFY. The CalDAV group might decide that notifications is out of scope, but at least it's worth discussing whether notifications are a MUST, a feature to do later, or a feature to not even think about right now. I suspect our job will be a lot simpler if we declare notifications out of scope for now, although I'd be happy to work on calendar event notifications next after CalDAV. Lisa On Aug 16, 2004, at 5:34 PM, TimHare@comcast.net wrote: > Sorry for the cross-post but it seems relevant. Let me preface this by > saying that I haven't read all of CalDAV yet - and I suspect I need to > be up to speed on DAV first. That said - it seems to me some of the > discussion going on now on the CalDAV list re: notifications and > client/server complexity are issues (either "also" or "instead") for > the Calsify list? > > Tim Hare > Interested Bystander, Non-Inc. > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify 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 i7HH4app002980 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 17 Aug 2004 10:04:37 -0700 In-Reply-To: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> References: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <805638E3-F06F-11D8-AB59-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] polling Date: Tue, 17 Aug 2004 10:04:29 -0700 To: Dan Winship X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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, 17 Aug 2004 17:04:37 -0000 There's another way to track deleted items, which is tombstones, which I prefer to IMAP-style sequence numbers. You'd give everything UIDs, as in your scheme, and mark some UIDs as deleted since timestamp T. I believe tombstones are much easier to track for both client and server in many situations, because each item has fewer dependencies on other items. Lisa On Aug 17, 2004, at 9:33 AM, Dan Winship wrote: > On Mon, 2004-08-16 at 14:36 -0700, Lisa Dusseault wrote: >> Dan Winship wrote: >>> I have some thoughts on a "polling for changes" REPORT that I'll post >>> tomorrow. >> >> Dan, if this could be used for generic WebDAV collections, I know of >> other groups who would be interested in this as a completely >> calendaring-independent WebDAV feature. > > Yes, it could be used generically in WebDAV. > > (The exact problem that the following protocol is trying to solve is > "make it possible for a client to find out about all modifications to, > additions to, and deletions from a collection since an arbitrary time > in > the past, without requiring the server to keep an unbounded amount of > historical data or per-client state".) > > Modify/addition polling is easy; you just need a uid and last-modified- > timestamp for every object in the collection, and when the client asks > the server "what's changed since TIME", it returns the uids of all > objects with modtimes > TIME. (And then the client requests whatever > additional data it needs for those UIDs. Or alternately, it could > specify as part of the REPORT request what properties it cares about, > and they could be returned as part of the report.) > > To allow polling for deletions, the objects in the collection need to > have IMAP-style sequence numbers (meaning "A relative position from 1 > to > the number of messages in the mailbox. As each new message is added, it > is assigned a message sequence number that is 1 higher than the number > of messages in the mailbox before that new message was added. ... When > a > message is removed from the mailbox, the message sequence number for > all > subsequent messages is decremented." This seems like it would have > something to do with WebDAV Ordered Collections, except that it would > be > a "server-maintained ordering", which is unspecified by that > document...). In addition to the sequence numbers, each object needs a > "predecessor deleted" timestamp that records the last time its > immediate > predecessor-in-sequence-number was deleted. When the client polls for > "what's changed since TIME", the deleted objects report contains the > uid > and sequence number of each object whose predecessor-deleted timestamp > is after TIME, and then the client deletes objects from its cache as > needed to make the sequence numbers match up. > > > I know that's not terribly clear, so here's an example. At noon, I > create a calendar with a bunch of items in it: > > Seq UID LastMod PredDel Summary DTSTART, etc > 1 306A 12:00 1970 Lunch 12:00 ... > 2 9294 12:00 1970 Conference call 11:00 ... > 3 5798 12:00 1970 Birthday party 17:00 ... > 4 0FEE 12:00 1970 Planning meeting 14:00 ... > 5 53A1 12:00 1970 Company holiday 2004-09-06 ... > > (where "1970" means "a timestamp which is earlier than the oldest item > in the collection".) > > Then, *from another client*, I make some changes. First the conference > call gets rescheduled, so I update its DTSTART, and the server updates > its modtime: > > 2 9294 *12:15* 1970 Conference call *13:00* ... > > Then the birthday party is canceled, so I deleted it, and the server > updates the predecessor-deleted time of the following item, and > decrements the sequence numbers of all following items: > > *3* 0FEE 12:00 *12:30* Planning meeting 14:00 ... > *4* 53A1 12:00 1970 Company holiday 2004-09-06 ... > > Then I add a new item: > > 5 99BB 12:45 1970 Vacation 2004-09-20 ... > > Then the planning meeting gets canceled too: > > *3* 53A1 12:00 *1:00* Company holiday 2004-09-06 ... > *4* 99BB 12:45 1970 Vacation 2004-09-20 ... > > So now the server has: > > Seq UID LastMod PredDel Summary DTSTART, etc > 1 306A 12:00 1970 Lunch 12:00 ... > 2 9294 12:15 1970 Conference call 13:00 ... > 3 53A1 12:00 1:00 Company holiday 2004-09-06 ... > 4 99BB 12:45 1970 Vacation 2004-09-20 ... > > while the original client still has the original version of the data > cached. So it asks, what's changed since 12:00, and the server responds > (in some appropriately XMLish way): > > 4 objects in collection > > Modified/Added uids: > 9294 > 99BB > > Removed objects before: > seq 3, uid 53A1 > > To handle the modified/added part, the client asks for whatever > properties it cares about on uids 9294 and 99BB. To handle the removed > part, it finds uid 53A1 in the cache, sees that it has sequence number > 5 > there, and so deletes its two immediate predecessors so it will have > sequence number 3 like in the report. At that point, it will be > synchronized with the server. (If there were multiple objects mentioned > in the removed part, they have to be synchronized in sequence number > order for things to work out correctly.) > > The "4 objects" part of the response isn't needed in this example, but > would have been needed if one or more objects had been deleted from the > end of the collection. > > -- Dan > > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7HGW2pp001292 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 17 Aug 2004 09:32:03 -0700 Received: (qmail 9437 invoked from network); 17 Aug 2004 16:31:48 -0000 Received: from outbound.ximian.com (HELO twelve-monkeys.boston.ximian.com) (130.57.170.250) by peabody.ximian.com with SMTP; 17 Aug 2004 16:31:48 -0000 From: Dan Winship To: ietf-caldav@osafoundation.org Content-Type: text/plain Date: Tue, 17 Aug 2004 12:33:46 -0400 Message-Id: <1092760426.27786.105.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.92 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] polling 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, 17 Aug 2004 16:32:04 -0000 On Mon, 2004-08-16 at 14:36 -0700, Lisa Dusseault wrote: > Dan Winship wrote: > > I have some thoughts on a "polling for changes" REPORT that I'll post > > tomorrow. > > Dan, if this could be used for generic WebDAV collections, I know of > other groups who would be interested in this as a completely > calendaring-independent WebDAV feature. Yes, it could be used generically in WebDAV. (The exact problem that the following protocol is trying to solve is "make it possible for a client to find out about all modifications to, additions to, and deletions from a collection since an arbitrary time in the past, without requiring the server to keep an unbounded amount of historical data or per-client state".) Modify/addition polling is easy; you just need a uid and last-modified- timestamp for every object in the collection, and when the client asks the server "what's changed since TIME", it returns the uids of all objects with modtimes > TIME. (And then the client requests whatever additional data it needs for those UIDs. Or alternately, it could specify as part of the REPORT request what properties it cares about, and they could be returned as part of the report.) To allow polling for deletions, the objects in the collection need to have IMAP-style sequence numbers (meaning "A relative position from 1 to the number of messages in the mailbox. As each new message is added, it is assigned a message sequence number that is 1 higher than the number of messages in the mailbox before that new message was added. ... When a message is removed from the mailbox, the message sequence number for all subsequent messages is decremented." This seems like it would have something to do with WebDAV Ordered Collections, except that it would be a "server-maintained ordering", which is unspecified by that document...). In addition to the sequence numbers, each object needs a "predecessor deleted" timestamp that records the last time its immediate predecessor-in-sequence-number was deleted. When the client polls for "what's changed since TIME", the deleted objects report contains the uid and sequence number of each object whose predecessor-deleted timestamp is after TIME, and then the client deletes objects from its cache as needed to make the sequence numbers match up. I know that's not terribly clear, so here's an example. At noon, I create a calendar with a bunch of items in it: Seq UID LastMod PredDel Summary DTSTART, etc 1 306A 12:00 1970 Lunch 12:00 ... 2 9294 12:00 1970 Conference call 11:00 ... 3 5798 12:00 1970 Birthday party 17:00 ... 4 0FEE 12:00 1970 Planning meeting 14:00 ... 5 53A1 12:00 1970 Company holiday 2004-09-06 ... (where "1970" means "a timestamp which is earlier than the oldest item in the collection".) Then, *from another client*, I make some changes. First the conference call gets rescheduled, so I update its DTSTART, and the server updates its modtime: 2 9294 *12:15* 1970 Conference call *13:00* ... Then the birthday party is canceled, so I deleted it, and the server updates the predecessor-deleted time of the following item, and decrements the sequence numbers of all following items: *3* 0FEE 12:00 *12:30* Planning meeting 14:00 ... *4* 53A1 12:00 1970 Company holiday 2004-09-06 ... Then I add a new item: 5 99BB 12:45 1970 Vacation 2004-09-20 ... Then the planning meeting gets canceled too: *3* 53A1 12:00 *1:00* Company holiday 2004-09-06 ... *4* 99BB 12:45 1970 Vacation 2004-09-20 ... So now the server has: Seq UID LastMod PredDel Summary DTSTART, etc 1 306A 12:00 1970 Lunch 12:00 ... 2 9294 12:15 1970 Conference call 13:00 ... 3 53A1 12:00 1:00 Company holiday 2004-09-06 ... 4 99BB 12:45 1970 Vacation 2004-09-20 ... while the original client still has the original version of the data cached. So it asks, what's changed since 12:00, and the server responds (in some appropriately XMLish way): 4 objects in collection Modified/Added uids: 9294 99BB Removed objects before: seq 3, uid 53A1 To handle the modified/added part, the client asks for whatever properties it cares about on uids 9294 and 99BB. To handle the removed part, it finds uid 53A1 in the cache, sees that it has sequence number 5 there, and so deletes its two immediate predecessors so it will have sequence number 3 like in the report. At that point, it will be synchronized with the server. (If there were multiple objects mentioned in the removed part, they have to be synchronized in sequence number order for things to work out correctly.) The "4 objects" part of the response isn't needed in this example, but would have been needed if one or more objects had been deleted from the end of the collection. -- Dan X-Envelope-From: TimHare@comcast.net Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7H0eVpo008736; Mon, 16 Aug 2004 17:40:31 -0700 Received: from thare.comcast.net (pcp05187532pcs.micske01.fl.comcast.net[68.46.236.23]) by comcast.net (sccrmhc11) with SMTP id <20040817004025011004ljrfe> (Authid: TimHare); Tue, 17 Aug 2004 00:40:25 +0000 Message-Id: <6.1.1.1.0.20040816202841.02832180@mail.comcast.net> X-Sender: TimHare@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Mon, 16 Aug 2004 20:34:44 -0400 To: ietf-calsify@osafoundation.org, ietf-caldav@osafoundation.org From: TimHare@comcast.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.39 Cc: Subject: [Ietf-caldav] Calsify list vs. CalDAV list? 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, 17 Aug 2004 00:40:31 -0000 Sorry for the cross-post but it seems relevant. Let me preface this by saying that I haven't read all of CalDAV yet - and I suspect I need to be up to speed on DAV first. That said - it seems to me some of the discussion going on now on the CalDAV list re: notifications and client/server complexity are issues (either "also" or "instead") for the Calsify list? Tim Hare Interested Bystander, Non-Inc. 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 i7GLpnpo022494 for ; Mon, 16 Aug 2004 14:51:49 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0F273281ACA; Mon, 16 Aug 2004 23:51:45 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 44F95281AC8; Mon, 16 Aug 2004 23:51:44 +0200 (CEST) In-Reply-To: <1092691370.27782.34.camel@twelve-monkeys.boston.ximian.com> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> <1092670951.14209.64.camel@twelve-monkeys.boston.ximian.com> <1092691370.27782.34.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <765AD65C-EFCE-11D8-B884-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Date: Mon, 16 Aug 2004 23:51:43 +0200 To: Dan Winship X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: Notifications [was Re: Client work] 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, 16 Aug 2004 21:51:50 -0000 On Aug 16, 2004, at 23:22, Dan Winship wrote: > I didn't mean that specific case sucks for clients, I meant the general > case sucks. The more ways the server can vary, the more stuff the > client > has to be able to deal with. This way lies IMAP. :) OK, I see ;-) > (Though dealing with N protocol levels is a lot nicer than dealing with > 2^N combinations of capabilities.) Yes, it needs to be coarse grained enough. To pickup Lisa's example of ACLs I thought about something like this: query the server whether it supports an ACL on a collection, if so, show the Evolution folder permission dialog, otherwise hide it from the menu (same thing on resources). This is a simple check and probably not too much work for you as a client developer ;-) Of course it might be hard to define proper "units". As another example a thin client might require a server supporting level 1 (DASL for range queries like in a week overview) or level 2 (complex reports) and refuse work otherwise, while a native client probably works with level 0 by caching all information locally and search there. This example matches on how IMAP4 is used. (eg the OGo IMAP4 web client needs bodystructure and server side sorting to work with acceptable speed while Mail.app doesn't care, caching everything locally). >> Well, you somehow imply that calendaring doesn't work in current >> servers because they don't have notifications ;-) > The proprietary client/server combinations do have notifications, and > the web-based systems don't need notifications because there's > generally > less of an expectation of having a completely live view. Exchange can probably consider industry standard and as you know notifications do not work reliably with that, forcing you to poll. QED ;-) I do not agree with you the point on the "live" view. This is more a problem for the users with sync solutions vs live solutions, not whether native or web. >> Polling is a simple DASL query (like you do in your Exchange connector >> ;-): > And we get lots of complaints that the views don't update fast > enough. :-) Because you do not support F5! ;-) How often to you currently poll in the connector? Is this just a problem because polling is expensive in Exchange or would it be a problem as well if you would poll every minute (or 30s, which would give you about 300-1000 concurrent users on a single server)? > But that could just be an argument for "notifications need to be > possible", not "notifications need to be mandatory". Exactly. Also easy for the client. Poll every 5 minutes in any case, if you get a notification, you get a "more live" view, if you don't, well it still works :-) > I have some thoughts on a "polling for changes" REPORT that I'll post > tomorrow. This REPORT thing is something I did not understand yet. Eg for cyclic appointments I would prefer a DASL query + a HTTP header (comparable to 'brief') or a special resource. But I need to look into that. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 i7GLaSpp021525 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 16 Aug 2004 14:36:28 -0700 In-Reply-To: <1092691370.27782.34.camel@twelve-monkeys.boston.ximian.com> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> <1092670951.14209.64.camel@twelve-monkeys.boston.ximian.com> <1092691370.27782.34.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <51394C51-EFCC-11D8-AB59-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Re: Notifications [was Re: Client work] Date: Mon, 16 Aug 2004 14:36:22 -0700 To: Dan Winship X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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: Mon, 16 Aug 2004 21:36:29 -0000 > > I have some thoughts on a "polling for changes" REPORT that I'll post > tomorrow. > > Dan, if this could be used for generic WebDAV collections, I know of other groups who would be interested in this as a completely calendaring-independent WebDAV feature. Lisa X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7GLL6pp020643 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Aug 2004 14:21:07 -0700 Received: (qmail 2557 invoked from network); 16 Aug 2004 21:20:59 -0000 Received: from outbound.ximian.com (HELO twelve-monkeys.boston.ximian.com) (130.57.170.250) by peabody.ximian.com with SMTP; 16 Aug 2004 21:20:59 -0000 From: Dan Winship To: Helge Hess In-Reply-To: References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> <1092670951.14209.64.camel@twelve-monkeys.boston.ximian.com> Content-Type: text/plain Date: Mon, 16 Aug 2004 17:22:50 -0400 Message-Id: <1092691370.27782.34.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.92 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: Notifications [was Re: Client work] 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, 16 Aug 2004 21:21:07 -0000 On Mon, 2004-08-16 at 22:27 +0200, Helge Hess wrote: > > 1. Have protocol levels / Capability strings (eg, CalDAV Server A > > allows appointments to recur forever, but CalDAV Server B > > doesn't). [sucks for client authors] > > I think this can be solved by HTTP error codes. (I would also be > interested in the exact case where this hits the client, some servers > might "flatten" the cycle [client push would require a client fetch and > loose the cycle info]) I didn't mean that specific case sucks for clients, I meant the general case sucks. The more ways the server can vary, the more stuff the client has to be able to deal with. This way lies IMAP. :) (Though dealing with N protocol levels is a lot nicer than dealing with 2^N combinations of capabilities.) > > And if you're going to have multiple people accessing the same > > calendars, then clients need to know when someone else changes > > something in one of them. Ideally that means notifications. > > At a minimum you need good polling support. > > Well, you somehow imply that calendaring doesn't work in current > servers because they don't have notifications ;-) The proprietary client/server combinations do have notifications, and the web-based systems don't need notifications because there's generally less of an expectation of having a completely live view. > Polling is a simple DASL query (like you do in your Exchange connector > ;-): And we get lots of complaints that the views don't update fast enough. :-) But that could just be an argument for "notifications need to be possible", not "notifications need to be mandatory". I have some thoughts on a "polling for changes" REPORT that I'll post tomorrow. -- Dan X-Envelope-From: helge.hess@opengroupware.org 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 i7GLIbpo020430; Mon, 16 Aug 2004 14:18:37 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id E45D8281A21; Mon, 16 Aug 2004 23:18:32 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 2FC66277902; Mon, 16 Aug 2004 23:18:32 +0200 (CEST) In-Reply-To: References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Date: Mon, 16 Aug 2004 23:18:31 +0200 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: Notifications [was Re: Client work] 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, 16 Aug 2004 21:18:38 -0000 On Aug 16, 2004, at 22:29, Lisa Dusseault wrote: > Interoperability could be achieved almost trivially with a trivial > standard but it wouldn't be very usable. Read: iCal-over-HTTP for groupware. Agreed. > Usability could be maximized with a complex protocol but it would be > only theoretical usability without good interoperability. CalDAV is a > stab at a compromise there and I welcome input from this list on where > the balance should lie. Excellent. > What do you think is too complex? I'm not entirely through thinking about all things. What comes to mind are: - notifications - reports - fanout / iMIP So far I made some notes on the document, I need to find the time to summarize and post them. > Evidently you think DASL is not too complex but Jabber is; that's > interesting because it's not the same position others would > necessarily take, since so many XMPP /Jabber libraries exist but few > (none?) DASL libraries. This is because of technology used in todays OpenSource groupware servers. Most are backed by a SQL database (OGo, PHPgroupware, e4l) or even some weird setups which use an IMAP4 server as the storage (eg Bynari, Kolab). Parsing (or generating) DASL isn't hard and DASL itself maps pretty well to SQL. It matches the existing server infrastructure. Notifications in contrast are "unnatural" for SQL servers, especially those with transaction support. To implement them, you probably need a separate daemon which handles that (by polling committed transactions, maybe with some additional trigger support). And for a server you need to setup Jabber in _addition_. DASL is just an additional RPC interface to the HTTP server (like WebDAV) while Jabber is something completely new and requires separate infrastructure. Not sure whether I was able to express my thoughts on that in understandable English, sorry :-| Let me know if I need to elaborate. Note: maybe for a "Level 0" I wouldn't even enforce DASL. Maybe this is already "Level 1" (as required for writing thin clients). Eg servers like Kolab (aka Cyrus) cannot support DASL (currently) because you can't search arbitary attributes in IMAP4. > Cyrus also proposed CalDAV "levels" where the first level was > basically what Apple does with iCal, so an even simpler "Level 0" than > what you propose. Yes, might make sense. Though I'm not sure why this would be called "DAV", because its just regular HTTP. > The reason ACL is a requirement in CalDAV is because the requirements > investigation that the CalSch WG did resulted in deciding that access > control was a requirement for a calendar access protocol. I don't > think it's actually a requirement, but I'd like some kind of rough > consensus before making it optional. This is something I need to think about. I guess this should be a level feature. We currently have no ACL support, but I guess it shouldn't be hard nor time consuming. Eg in our Outlook plugin the user currently has not possibility to configure permissions. If he tries to write an readonly appointment, the server will issue a HTTP 403 and Outlook will give the user the option to either throw away the changes or save the appointment in some other folder. Apparently this is OK for our customers ;-), so I would assume that this isn't a required feature for clients. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 i7GKTUpp016826 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 16 Aug 2004 13:29:30 -0700 In-Reply-To: <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Mon, 16 Aug 2004 13:29:23 -0700 To: Helge Hess X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: Notifications [was Re: Client work] 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, 16 Aug 2004 20:29:31 -0000 > Personally my goal is too bring as many _available_ servers and > clients together - I'm not sure about your intention (produce a spec > which covers all features of Chandler?). That's certainly not my goal -- that would not be conducive to developing a standard, let alone to achieving interoperability. My goal was to maximize interoperability and usability together, which of course trade off against each other. Interoperability could be achieved almost trivially with a trivial standard but it wouldn't be very usable. Usability could be maximized with a complex protocol but it would be only theoretical usability without good interoperability. CalDAV is a stab at a compromise there and I welcome input from this list on where the balance should lie. > Currently the only "protocol" which is more or less interoperable > between servers is iCal-File-over-HTTP. And this one is really > inappropriate for almost anything ;-) > > For OGo we "solve" the situation only by implementing all the various > protocols starting with iCal/HTTP, Exchange WebDAV, WCAP, > XML-RPC(variants), RSS etc used by the clients. It is a mess that this > is required even for basic things. > To summarize: my _strong_ fear is that if CalDAV ends up being too > complex, few will implement it. The mentioned notification is > certainly one thing which would require a major amount of work in > existing servers (including OGo and PHPgroupware). What do you think is too complex? Evidently you think DASL is not too complex but Jabber is; that's interesting because it's not the same position others would necessarily take, since so many XMPP /Jabber libraries exist but few (none?) DASL libraries. > Maybe the "level" idea is good?: > CalDAV Level 0: basic DAV/iCal storage of iCal objects + DASL queries > CalDAV Level 1: Level 0 + more complex cal support (fanout, reports?) > CalDAV Level 2: Level 1 + Jabber notifications > What do you think? A calendaring system can work without level 1 and 2 > features. Instead of levels we could also use separate documents (like > WebDAV ACL and DASL is separate from WebDAV and certainly not required > for a lot of clients). > > (BTW: I think it is already hard enough to make other server vendors > implement DAV/DASL/ACLs properly ..., I already did a lot of talks > with PHPgroupware and exchange4linux people on this ;-) > Cyrus also proposed CalDAV "levels" where the first level was basically what Apple does with iCal, so an even simpler "Level 0" than what you propose. The reason ACL is a requirement in CalDAV is because the requirements investigation that the CalSch WG did resulted in deciding that access control was a requirement for a calendar access protocol. I don't think it's actually a requirement, but I'd like some kind of rough consensus before making it optional. 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 i7GKRSpo016604 for ; Mon, 16 Aug 2004 13:27:28 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id E6B382817BE; Mon, 16 Aug 2004 22:27:22 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 38F14281553; Mon, 16 Aug 2004 22:27:22 +0200 (CEST) In-Reply-To: <1092670951.14209.64.camel@twelve-monkeys.boston.ximian.com> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> <1092670951.14209.64.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Date: Mon, 16 Aug 2004 22:27:21 +0200 To: Dan Winship X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: Notifications [was Re: Client work] 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, 16 Aug 2004 20:27:29 -0000 On Aug 16, 2004, at 17:42, Dan Winship wrote: >> Personally my goal is to bring as many _available_ servers and clients >> together > With how much work on the servers? For "level 0" applications only with the work required to implement the protocol. No functional additions should be necessary. Do "we" write a design document on how the "perfect" server looks like or do we want to find a sane standard protocol which ensures interoperability? For me the latter is the important thing and requires special attention (eg WebDAV is pretty much focused on that, eg rejecting things because it might break Java servlet based servers, sigh). But as mentioned I can't tell about Lisa's motivation. It sounded a bit like "specify how it should work, then implement if no one else does", but I might have got that wrong. She should comment ;-) > What will CalDAV's position towards existing servers be? Hopefully interoperability. > 1. Have protocol levels / Capability strings (eg, CalDAV Server A > allows appointments to recur forever, but CalDAV Server B > doesn't). [sucks for client authors] I think this can be solved by HTTP error codes. (I would also be interested in the exact case where this hits the client, some servers might "flatten" the cycle [client push would require a client fetch and loose the cycle info]) > 2. Ignore the existing servers, force them to comply with our > model > [sucks for server authors] Certainly won't work unless there are sufficient interesting clients implementing CalDAV which leads to chicken and egg ;-) Few will use CalDAV if it is easier to implement a client side plugin than to implement the protocol (see Outlook). Eg implementing an Evolution plugin is rather easy now. Same goes for Kontact. > 3. Support the least common denominator of functionality [sucks > for > everyone] Si. This is why I think protocol levels might be quite a good solution for that. >> Currently the only "protocol" which is more or less interoperable >> between servers is iCal-File-over-HTTP. And this one is really >> inappropriate for almost anything ;-) > So assuming we're targeting a higher level of functionality than iCal- > file-over-HTTP, what functionality would that be? Being pragmatic for now I'm mostly interested in a Level 0 which would be just: - each iCal resource an individual HTTP resource - therefore proper locking etc - queries using DASL - maybe ACL support I know that this isn't perfect, but already makes calendaring interoperability 1000% better from what it is now. Then we can work on additions to add things like fanout or reports. > It seems to me like there are two big things you can do with a real > calendar server that you can't do well with just iCal-over-HTTP: thin > clients, and shared access to calendars (eg, public folders, accessing > other users' calendars / them accessing your calendar, direct booking > of > resource calendars, etc). The latter is the more important thing, shared access. At least I am talking about groupware here, not about PIM, and this implies shared folders. > And if you're going to have multiple people accessing the same > calendars, then clients need to know when someone else changes > something in one of them. Ideally that means notifications. > At a minimum you need good polling support. Well, you somehow imply that calendaring doesn't work in current servers because they don't have notifications ;-) Polling is a simple DASL query (like you do in your Exchange connector ;-): SELECT uid,sequence FROM /users/dan/Calendar; or maybe SELECT uid,etag FROM /users/dan/Calendar; since uid and sequence are promoted from the iCal. I think this works fine for 90% of the cases. "Real" notifications would require a separate event service (and state handler for that) on the server and a lot of systems won't add this (probably impossible in practice with a PHP or Servlet centric solution). Notably version-set snapshots really belong on the client/device, since they are cache specific. >> To summarize: my _strong_ fear is that if CalDAV ends up being too >> complex, few will implement it. The mentioned notification is >> certainly >> one thing which would require a major amount of work in existing >> servers (including OGo and PHPgroupware). > Are you worried about jabber-based notifications specifically, or > notifications/polling in general? a) I think if we specify notifications, we definitely should go with Jabber b) yes, I'm worried about notifications, because they imply major additions on existing servers c) polling should be no problem if it is stateless as in the example above BTW: OGo would probably implement Jabber notifications, but this would be an optional component and makes setup more difficult. Also while we are positive on this, it would nevertheless be quite an amount of work (means: takes a lot of time unless we find a sponsor for that ;-). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 i7GKNMpp016432 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 16 Aug 2004 13:23:22 -0700 In-Reply-To: <7C842486-EE17-11D8-B7DE-000D93C1A604@opengroupware.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <3DD1AEFA-ED4C-11D8-8EB5-000A95B2BB72@osafoundation.org> <7C842486-EE17-11D8-B7DE-000D93C1A604@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1A90DEC6-EFC2-11D8-AB59-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] CalDAV Client work? Date: Mon, 16 Aug 2004 13:23:15 -0700 To: Helge Hess X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Cc: Stuart Parmenter , Sheila Mooney , 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: Mon, 16 Aug 2004 20:23:23 -0000 Right now, integration would be barely possible but certainly not stable. Until we move to publishing something based on a standard format, other projects could integrate with Chandler as a one-off project -- not too hard but certainly extra work. The attributes Chandler uses internally aren't pure iCalendar data, although of course there's some similarity. Lisa On Aug 14, 2004, at 10:29 AM, Helge Hess wrote: > On Aug 13, 2004, at 19:14, Lisa Dusseault wrote: >>>> Chandler also uses vanilla WebDAV to share its content items of all >>>> types >>> Could you elaborate? How does it use WebDAV for that? >> >> We're currently working on a spec and an implementation for that. >> Some highlights of the current plan: >> - Chandler collections are mapped to WebDAV collections >> - Chandler content items are mapped to one or more WebDAV resources >> - Chandler attributes on items are mapped to WebDAV properties >> - Thus, a user will be able to publish a calendar by selecting the >> collection and uploading it to a new WebDAV collection, and another >> client can download the calendar or be granted shared access to the >> event items in the calendar >> - Both the initial calendar publisher and the people sharing the >> calendar will synchronize changes periodically > > Sounds good :-) > > Because the Chandler attributes are something non-standard this won't > be useful for integration? Or do the attributes follow some "standard" > (eg match iCal/xCal properties)? > > Greets, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7GFekpp023029 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Aug 2004 08:40:47 -0700 Received: (qmail 409 invoked from network); 16 Aug 2004 15:40:40 -0000 Received: from outbound.ximian.com (HELO twelve-monkeys.boston.ximian.com) (130.57.170.250) by peabody.ximian.com with SMTP; 16 Aug 2004 15:40:40 -0000 From: Dan Winship To: Helge Hess In-Reply-To: <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> Content-Type: text/plain Date: Mon, 16 Aug 2004 11:42:31 -0400 Message-Id: <1092670951.14209.64.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.92 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: Notifications [was Re: Client work] 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, 16 Aug 2004 15:40:48 -0000 On Sat, 2004-08-14 at 16:31 +0200, Helge Hess wrote: > But can we agree that this is out of scope for the "basic" CalDAV > specification or an "optional" part, eg using protocol levels like in > WebDAV? > > Personally my goal is to bring as many _available_ servers and clients > together With how much work on the servers? What will CalDAV's position towards existing servers be? 1. Have protocol levels / Capability strings (eg, CalDAV Server A allows appointments to recur forever, but CalDAV Server B doesn't). [sucks for client authors] 2. Ignore the existing servers, force them to comply with our model [sucks for server authors] 3. Support the least common denominator of functionality [sucks for everyone] > - I'm not sure about [Lisa's] intention (produce a spec which > covers all features of Chandler?). > > Currently the only "protocol" which is more or less interoperable > between servers is iCal-File-over-HTTP. And this one is really > inappropriate for almost anything ;-) So assuming we're targeting a higher level of functionality than iCal- file-over-HTTP, what functionality would that be? It seems to me like there are two big things you can do with a real calendar server that you can't do well with just iCal-over-HTTP: thin clients, and shared access to calendars (eg, public folders, accessing other users' calendars / them accessing your calendar, direct booking of resource calendars, etc). And if you're going to have multiple people accessing the same calendars, then clients need to know when someone else changes something in one of them. Ideally that means notifications. At a minimum you need good polling support. > To summarize: my _strong_ fear is that if CalDAV ends up being too > complex, few will implement it. The mentioned notification is certainly > one thing which would require a major amount of work in existing > servers (including OGo and PHPgroupware). Are you worried about jabber-based notifications specifically, or notifications/polling in general? -- Dan X-Envelope-From: hildjj@gmail.com X-Envelope-To: Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7EIxLpo009886 for ; Sat, 14 Aug 2004 11:59:21 -0700 Received: by mproxy.gmail.com with SMTP id 78so43511rnk for ; Sat, 14 Aug 2004 11:59:16 -0700 (PDT) Received: by 10.38.89.36 with SMTP id m36mr4569rnb; Sat, 14 Aug 2004 11:59:16 -0700 (PDT) Message-ID: <82777bea0408141159b11ab27@mail.gmail.com> Date: Sat, 14 Aug 2004 12:59:16 -0600 From: Joe Hildebrand To: shaver@off.net Subject: Re: [Ietf-caldav] Notifications [was Re: Client work] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Joe Hildebrand List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2004 18:59:23 -0000 Yes, we can use HTTP CONNECT; that works fine. There are also a couple of approaches for tunneling through ALG's, using polling techniques. This one is pretty widely implemented, but has some issues: http://www.jabber.org/jeps/jep-0025.html This one is intentended to eventually replace it, once we reach some consensus: http://www.jabber.org/jeps/jep-0124.html -- Joe Hildebrand On Fri, 13 Aug 2004 12:57:50 -0400, Mike Shaver wrote: > On Fri, 13 Aug 2004 09:06:24 -0700, Lisa Dusseault > wrote: > > It's my opinion that we can do much better than HTTP for notifications > > if we're willing to work a little harder! > > That sounds pretty good, though I think one of the great things about > an HTTP-driven protocol is the firewall-transit capabilities. Perhaps > we can use corkscrew[1]-like techniques to establish a long-lived XMPP > connection over an HTTP proxy, but I would be much happier to see some > sort of "what's new since [opaque server token returned at last update > fetch]?" poll command included as well, similar to the POP extensions > along those lines. > > Strong language to encourage clients to use XMPP with HTTP layering > before falling back on polling would be very welcome in the standard, > of course, but I think it's important to be able to get some sort of > periodic update even if you can only use HTTP for a given > configuration. > > [1]: http://www.agroman.net/corkscrew/ > > Mike > > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > X-Envelope-From: helge.hess@opengroupware.org 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 i7EHTWpo005318; Sat, 14 Aug 2004 10:29:33 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id C8C2C27DC8A; Sat, 14 Aug 2004 19:29:30 +0200 (CEST) Received: from [192.168.102.125] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 5BC83281960; Sat, 14 Aug 2004 19:29:28 +0200 (CEST) In-Reply-To: <3DD1AEFA-ED4C-11D8-8EB5-000A95B2BB72@osafoundation.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <3DD1AEFA-ED4C-11D8-8EB5-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C842486-EE17-11D8-B7DE-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] CalDAV Client work? Date: Sat, 14 Aug 2004 19:29:24 +0200 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: Stuart Parmenter , Sheila Mooney , 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: Sat, 14 Aug 2004 17:29:33 -0000 On Aug 13, 2004, at 19:14, Lisa Dusseault wrote: >>> Chandler also uses vanilla WebDAV to share its content items of all >>> types >> Could you elaborate? How does it use WebDAV for that? > > We're currently working on a spec and an implementation for that. > Some highlights of the current plan: > - Chandler collections are mapped to WebDAV collections > - Chandler content items are mapped to one or more WebDAV resources > - Chandler attributes on items are mapped to WebDAV properties > - Thus, a user will be able to publish a calendar by selecting the > collection and uploading it to a new WebDAV collection, and another > client can download the calendar or be granted shared access to the > event items in the calendar > - Both the initial calendar publisher and the people sharing the > calendar will synchronize changes periodically Sounds good :-) Because the Chandler attributes are something non-standard this won't be useful for integration? Or do the attributes follow some "standard" (eg match iCal/xCal properties)? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: helge.hess@opengroupware.org 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 i7EEVDpo025844; Sat, 14 Aug 2004 07:31:14 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id AA8A82817A9; Sat, 14 Aug 2004 16:31:08 +0200 (CEST) Received: from [192.168.102.125] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id D649E281797; Sat, 14 Aug 2004 16:31:07 +0200 (CEST) In-Reply-To: References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <92695728-EDFE-11D8-B7DE-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Date: Sat, 14 Aug 2004 16:31:04 +0200 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Re: Notifications [was Re: Client work] 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: Sat, 14 Aug 2004 14:31:15 -0000 On Aug 13, 2004, at 18:06, Lisa Dusseault wrote: > It's my opinion that we can do much better than HTTP for notifications > if we're willing to work a little harder! Yes, I absolutely agree. Using Jabber for that is certainly a good and reliable approach. The only issue I have with that is that it adds another relatively complex component to the server infrastructure (while httpu is pretty easy to implement). But can we agree that this is out of scope for the "basic" CalDAV specification or an "optional" part, eg using protocol levels like in WebDAV? Personally my goal is too bring as many _available_ servers and clients together - I'm not sure about your intention (produce a spec which covers all features of Chandler?). Currently the only "protocol" which is more or less interoperable between servers is iCal-File-over-HTTP. And this one is really inappropriate for almost anything ;-) For OGo we "solve" the situation only by implementing all the various protocols starting with iCal/HTTP, Exchange WebDAV, WCAP, XML-RPC(variants), RSS etc used by the clients. It is a mess that this is required even for basic things. To summarize: my _strong_ fear is that if CalDAV ends up being too complex, few will implement it. The mentioned notification is certainly one thing which would require a major amount of work in existing servers (including OGo and PHPgroupware). Maybe the "level" idea is good?: CalDAV Level 0: basic DAV/iCal storage of iCal objects + DASL queries CalDAV Level 1: Level 0 + more complex cal support (fanout, reports?) CalDAV Level 2: Level 1 + Jabber notifications What do you think? A calendaring system can work without level 1 and 2 features. Instead of levels we could also use separate documents (like WebDAV ACL and DASL is separate from WebDAV and certainly not required for a lot of clients). (BTW: I think it is already hard enough to make other server vendors implement DAV/DASL/ACLs properly ..., I already did a lot of talks with PHPgroupware and exchange4linux people on this ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7DHEepp030066 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 Aug 2004 10:14:42 -0700 In-Reply-To: <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3DD1AEFA-ED4C-11D8-8EB5-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] CalDAV Client work? Date: Fri, 13 Aug 2004 10:14:31 -0700 To: Helge Hess X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Cc: Stuart Parmenter , Sheila Mooney , 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: Fri, 13 Aug 2004 17:14:44 -0000 >> Chandler also uses vanilla WebDAV to share its content items of all >> types > > Could you elaborate? How does it use WebDAV for that? > We're currently working on a spec and an implementation for that. Some highlights of the current plan: - Chandler collections are mapped to WebDAV collections - Chandler content items are mapped to one or more WebDAV resources - Chandler attributes on items are mapped to WebDAV properties - Thus, a user will be able to publish a calendar by selecting the collection and uploading it to a new WebDAV collection, and another client can download the calendar or be granted shared access to the event items in the calendar - Both the initial calendar publisher and the people sharing the calendar will synchronize changes periodically Lisa X-Envelope-From: mike.shaver@gmail.com X-Envelope-To: Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7DGxUpo022744 for ; Fri, 13 Aug 2004 09:59:30 -0700 Received: by mproxy.gmail.com with SMTP id 73so27754rnl for ; Fri, 13 Aug 2004 09:59:20 -0700 (PDT) Received: by 10.38.11.76 with SMTP id 76mr191674rnk; Fri, 13 Aug 2004 09:59:20 -0700 (PDT) Message-ID: Date: Fri, 13 Aug 2004 12:57:50 -0400 From: Mike Shaver To: Lisa Dusseault Subject: Re: [Ietf-caldav] Notifications [was Re: Client work] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: shaver@off.net 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, 13 Aug 2004 16:59:31 -0000 On Fri, 13 Aug 2004 09:06:24 -0700, Lisa Dusseault wrote: > It's my opinion that we can do much better than HTTP for notifications > if we're willing to work a little harder! That sounds pretty good, though I think one of the great things about an HTTP-driven protocol is the firewall-transit capabilities. Perhaps we can use corkscrew[1]-like techniques to establish a long-lived XMPP connection over an HTTP proxy, but I would be much happier to see some sort of "what's new since [opaque server token returned at last update fetch]?" poll command included as well, similar to the POP extensions along those lines. Strong language to encourage clients to use XMPP with HTTP layering before falling back on polling would be very welcome in the standard, of course, but I think it's important to be able to get some sort of periodic update even if you can only use HTTP for a given configuration. [1]: http://www.agroman.net/corkscrew/ Mike X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7DG6Xpp014759 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 13 Aug 2004 09:06:43 -0700 In-Reply-To: <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Date: Fri, 13 Aug 2004 09:06:24 -0700 To: Dan Winship X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 Cc: ietf-caldav@osafoundation.org Subject: [Ietf-caldav] Notifications [was Re: Client work] 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, 13 Aug 2004 16:06:44 -0000 It's my opinion that we can do much better than HTTP for notifications if we're willing to work a little harder! I've been working with the XMPP (Jabber) people to first get XMPP standardized (we should get RFC #s any day now), then define a publish/subscribe model (http://www.jabber.org/jeps/jep-0060.html) for arbitrary machine-readable notifications, such as calendar alarms, new invitations, changes to shared events. XMPP is particularly good at this because you can route notifications to a specific piece of software, by going through the user's single permanent connection to their XMPP server. Also you can easily tell when they're not online and avoid routing useless notifications at all. Lisa On Aug 13, 2004, at 7:26 AM, Dan Winship wrote: > On Fri, 2004-08-13 at 01:56 +0200, Helge Hess wrote: >>> Also, how to make the non-persistent connection model still appear >>> responsive to users -- e.g. notifications through a notification >>> channel, to trigger a synch action, rather than constant polling. >> >> Exchange uses httpu (HTTP over UDP) to notify clients on changes. I'm >> not yet sure whether this is a good approach, it might be. > > It's not great. It requires the server to be able to source packets > back > to the client, which doesn't work in a lot of situations, notably: > 1. If the user is behind a NAT (at home, using a wireless hotspot, > etc) > 2. If the user is behind someone else's firewall (at a customer > site) > 3. If the user is inside his company's firewall, but the Exchange > server is in a DMZ > > But then, the same would be true of any solution that doesn't require > the client to keep a connection open (unless you assume lots of > infrastructure). > > OTOH, assuming that the client is sending requests to the server on a > regular basis anyway, the server could just sneak the notifications > into > the HTTP conversation, either via a response header or a new 1xx > response code. (Both of those seem technically wrong according to the > HTTP model, but then, notifications are totally outside the HTTP model, > so that's not surprising :) > > -- Dan > > X-Envelope-From: helge.hess@opengroupware.org 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 i7DEcjpo014619; Fri, 13 Aug 2004 07:38:45 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 2B56C28159D; Fri, 13 Aug 2004 16:36:41 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id B3CAB2815A7; Fri, 13 Aug 2004 16:36:40 +0200 (CEST) In-Reply-To: <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7696CD2B-ED36-11D8-B7DE-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] CalDAV Client work? Date: Fri, 13 Aug 2004 16:38:38 +0200 To: Dan Winship X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Fri, 13 Aug 2004 14:38:47 -0000 On Aug 13, 2004, at 16:26, Dan Winship wrote: >> Exchange uses httpu (HTTP over UDP) to notify clients on changes. I'm >> not yet sure whether this is a good approach, it might be. > It's not great. It requires the server to be able to source packets > back > to the client, which doesn't work in a lot of situations, notably: Well, the question is on the goal. I would use it like that: - you are required to poll to get notified of changes - optionally the server can provide UDP notification In practice I would set my client to poll every 2-5 minutes or so, which works great in the cafe or at home where the connection is slower anyway, and if I'm in the office I can get almost instant updates using UDP. Sounds OK for me. But as mentioned in the draft we probably should leave that out of the CalDAV specification? I guess this should be an additional draft. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org X-Envelope-From: danw@novell.com X-Envelope-To: Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i7DEPHpp010169 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 13 Aug 2004 07:25:18 -0700 Received: (qmail 28337 invoked from network); 13 Aug 2004 14:25:08 -0000 Received: from outbound.ximian.com (HELO twelve-monkeys.boston.ximian.com) (130.57.170.250) by peabody.ximian.com with SMTP; 13 Aug 2004 14:25:08 -0000 Subject: Re: [Ietf-caldav] CalDAV Client work? From: Dan Winship To: Helge Hess In-Reply-To: <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> Content-Type: text/plain Date: Fri, 13 Aug 2004 10:26:36 -0400 Message-Id: <1092407196.31779.30.camel@twelve-monkeys.boston.ximian.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.92 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 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: Fri, 13 Aug 2004 14:25:19 -0000 On Fri, 2004-08-13 at 01:56 +0200, Helge Hess wrote: > > Also, how to make the non-persistent connection model still appear > > responsive to users -- e.g. notifications through a notification > > channel, to trigger a synch action, rather than constant polling. > > Exchange uses httpu (HTTP over UDP) to notify clients on changes. I'm > not yet sure whether this is a good approach, it might be. It's not great. It requires the server to be able to source packets back to the client, which doesn't work in a lot of situations, notably: 1. If the user is behind a NAT (at home, using a wireless hotspot, etc) 2. If the user is behind someone else's firewall (at a customer site) 3. If the user is inside his company's firewall, but the Exchange server is in a DMZ But then, the same would be true of any solution that doesn't require the client to keep a connection open (unless you assume lots of infrastructure). OTOH, assuming that the client is sending requests to the server on a regular basis anyway, the server could just sneak the notifications into the HTTP conversation, either via a response header or a new 1xx response code. (Both of those seem technically wrong according to the HTTP model, but then, notifications are totally outside the HTTP model, so that's not surprising :) -- Dan X-Envelope-From: helge.hess@opengroupware.org 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 i7CNuXpo008161; Thu, 12 Aug 2004 16:56:33 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 0D706281798; Fri, 13 Aug 2004 01:54:22 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 96624281797; Fri, 13 Aug 2004 01:54:21 +0200 (CEST) In-Reply-To: <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3752E3DB-ECBB-11D8-B7DE-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] CalDAV Client work? Date: Fri, 13 Aug 2004 01:56:23 +0200 To: Lisa Dusseault X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 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: Thu, 12 Aug 2004 23:56:35 -0000 On Aug 12, 2004, at 21:46, Lisa Dusseault wrote: > Things that will affect that schedule: > - will somebody else make available a CalDAV server in that time, for > us to test against > - will somebody else work on an open source CalDAV server > implementation, so we don't have to expend effort in that direction as > well As mentioned we (OGo) probably step in. I'll post some comments on the CalDAV draft later, but in general this draft is something we have been waiting for. Personally I hope for some kind of "joined" development to avoid the chicken&egg issue (this will never be usefully implemented if the client developers wait for a fully functional server and the reverse ...). > Chandler also uses vanilla WebDAV to share its content items of all > types Could you elaborate? How does it use WebDAV for that? > We certainly intend to have short-lived connections where possible, > and to avoid the IMAP-style permanent-connection world where possible > (of course we have to do IMAP though). Exactly. This is one reason why we have choosen WebDAV for the OGo Outlook connector. > That's why features like SEARCH method aren't so important to the > single-user Chandler use cases -- we plan to have the user's own data > all synchronized locally, so why not do the search locally. Note that in general I agree (especially for simplicity in the client), but to comment anyway: a) Because a search is not necessarily more expensive than a "check for updates", so you get an implicit update if you do a search b) a fat SQL database on the server is definitely faster in processing a big (really big) calendar than a db4 (or something similiar) database on localhost, especially on real world PCs (GHz PCs are _not_ in widespread deployment and won't be anytime soon) > In the long run, we may look at things like how to make WebDAV > synchronization work better -- e.g. a feature track property changes, > as well as the existing HTTP ETag which tracks only entity (body) > changes. Yes, this is also something we are very much interested in for out Outlook connector. Currently we use a "special" URL for that (getIDsAndVersions resources in any ZideStore collection). > Also, how to make the non-persistent connection model still appear > responsive to users -- e.g. notifications through a notification > channel, to trigger a synch action, rather than constant polling. Exchange uses httpu (HTTP over UDP) to notify clients on changes. I'm not yet sure whether this is a good approach, it might be. I have the impression that polling works best in real live, especially in RDBMS backed groupware systems which make useful notification a bit hard (and basically results in a polling service on the service side). Also note that server triggered notification can easily lead to DoS like behaviour if not implemented with great care (a major scalability concern in projects we work in where a single server hosts tens of thousands of users). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org 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 i7CJknpp022867 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 12 Aug 2004 12:46:55 -0700 In-Reply-To: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> References: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54B69603-EC98-11D8-8EB5-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] CalDAV Client work? Date: Thu, 12 Aug 2004 12:46:40 -0700 To: Helge Hess X-Mailer: Apple Mail (2.618) X-Scanned-By: MIMEDefang 2.39 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: Thu, 12 Aug 2004 19:46:59 -0000 The current plan for Chandler is to implement CalDAV, but not in the 0.4 release which is slated for Sept/Oct -- likely the 0.5 release but who knows for sure. Things that will affect that schedule: - will somebody else make available a CalDAV server in that time, for us to test against - will somebody else work on an open source CalDAV server implementation, so we don't have to expend effort in that direction as well - normal vagaries of software development Chandler also uses vanilla WebDAV to share its content items of all types, and we'll have experimentally usable code that does that in 0.4. We certainly intend to have short-lived connections where possible, and to avoid the IMAP-style permanent-connection world where possible (of course we have to do IMAP though). Since good offline functionality is key to the Chandler vision, we definitely intend to keep the client synchronized with the server as much as possible. That's why features like SEARCH method aren't so important to the single-user Chandler use cases -- we plan to have the user's own data all synchronized locally, so why not do the search locally. In the long run, we may look at things like how to make WebDAV synchronization work better -- e.g. a feature track property changes, as well as the existing HTTP ETag which tracks only entity (body) changes. Also, how to make the non-persistent connection model still appear responsive to users -- e.g. notifications through a notification channel, to trigger a synch action, rather than constant polling. Lisa On Aug 11, 2004, at 3:13 PM, Helge Hess wrote: > Well, > > anyone working on client software which implements CalDAV? > > Lisa, can we expect Chandler to implement CalDAV any time soon? I > guess it would probably synchronize server data into its own > repository instead of having a "live" connection? > > I think the OGo project would invest some work into adding CalDAV as a > protocol. We already implement some parts of Exchange WebDAV protocol > and patches for CalDAV shouldn't be too much work. Having some client > vendor to work with would be of course great ;-) > > best regards, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > > _______________________________________________ > Ietf-caldav mailing list > Ietf-caldav@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav 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 i7BMDEpo018905 for ; Wed, 11 Aug 2004 15:13:15 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id F07EC27EFA0 for ; Thu, 12 Aug 2004 00:11:06 +0200 (CEST) Received: from [192.168.101.126] (unknown [213.187.86.104]) by mail.mdlink.net (Postfix) with ESMTP id 57AF927F254 for ; Thu, 12 Aug 2004 00:11:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <9F2AC5C4-EBE3-11D8-8495-000D93C1A604@opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf-caldav@osafoundation.org From: Helge Hess Date: Thu, 12 Aug 2004 00:13:06 +0200 X-Mailer: Apple Mail (2.619) X-Scanned-By: MIMEDefang 2.39 Subject: [Ietf-caldav] CalDAV Client work? 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, 11 Aug 2004 22:13:15 -0000 Well, anyone working on client software which implements CalDAV? Lisa, can we expect Chandler to implement CalDAV any time soon? I guess it would probably synchronize server data into its own repository instead of having a "live" connection? I think the OGo project would invest some work into adding CalDAV as a protocol. We already implement some parts of Exchange WebDAV protocol and patches for CalDAV shouldn't be too much work. Having some client vendor to work with would be of course great ;-) best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org