Subject: Re: [Ietf-caldav] Creating a calendar
From: Elias Sinderson <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Fri, 27 Aug 2004 09:49:58 -0700
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar
Date: Fri, 27 Aug 2004 05:13:13 +0200
To: CalDAV DevList <[email-masked]>

On Aug 27, 2004, at 4:37, [email-masked] 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

Date: Thu, 26 Aug 2004 22:37:15 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-caldav] Creating a calendar

>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. 

Date: Thu, 26 Aug 2004 22:25:13 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar

Cyrus Daboo wrote:

> Hi Bernard,
> 
> --On Thursday, August 26, 2004 4:05 PM -0400 Bernard Desruisseaux 
> <[email-masked]> 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

Date: Thu, 26 Aug 2004 20:56:08 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar

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
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 
> 

Date: Thu, 26 Aug 2004 17:54:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar
Cc: 

Hi Helge,

--On Thursday, August 26, 2004 11:26 PM +0200 Helge Hess 
<[email-masked]> 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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar
Date: Thu, 26 Aug 2004 23:26:01 +0200
To: CalDAV DevList <[email-masked]>

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

Date: Thu, 26 Aug 2004 17:18:11 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar
Cc: CalDAV DevList <[email-masked]>

Hi Lisa,

--On Thursday, August 26, 2004 1:54 PM -0700 Lisa Dusseault 
<[email-masked]> 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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar
Date: Thu, 26 Aug 2004 13:54:30 -0700
To: Bernard Desruisseaux <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Thu, 26 Aug 2004 16:37:25 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar
Cc: 

--==========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 
<[email-masked]> 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

       <?xml version="1.0" encoding="utf-8" ?>>
       <report xmlns="DAV:">
          <c:calendar-store-namespace 
xmlns:c="http://www.example.com/caldav" />
       </report>

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

       <?xml version="1.0" encoding="utf-8" ?>
       <c:calendar-namespace-response 
xmlns:c="http://www.example.com/caldav">
         <c:calendar-namespace type="personal">
           <c:href>/calendars/user/joe</c:href>
           <c:namespace-display-name>My Calendars</c:namespace-display-name>
           <c:namespace-description>Your calendars</c:namespace-description>
         </c:calendar-namespace>
         <c:calendar-namespace type="shared">
           <c:href>/calendars/user</c:href>
           <c:namespace-display-name>Other Users' 
Calendars</c:namespace-display-name>
           <c:namespace-description>Calendars belonging to other users that 
have been shared with you</c:namespace-description>
         </c:calendar-namespace>
         <c:calendar-namespace type="public">
           <c:href>/calendars/public</c:href>
           <c:namespace-display-name>Public 
Calendars</c:namespace-display-name>
           <c:namespace-description>Calendars available to all 
users</c:namespace-description>
         </c:calendar-namespace>
         <c:calendar-namespace type="timezones">
           <c:href>/calendars/timezones</c:href>
         </c:calendar-namespace>
       </c:calendar-namespace-response>

--==========54CD4866E66C8860203B==========--

Date: Thu, 26 Aug 2004 16:05:46 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Creating a calendar

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.
> 
> 

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] The VALARM problem
Date: Wed, 25 Aug 2004 17:00:21 -0700
To: Cyrus Daboo <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

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  
> <[email-masked]> 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:
>>
>> <D:prop xmlns:D="DAV:">
>>    <C:valarms xmlns:C="urn:ietf:params:xml:ns:calsch">
>>
>> <D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid52</ 
>> D:
>> href>
>>
>> <D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid58</ 
>> D:
>> href>
>>    </C:valarms>
>> </D:prop>
>>
>> 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Wed, 25 Aug 2004 17:13:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Data model issue
Cc: CalDAV DevList <[email-masked]>

Hi Lisa,

--On Wednesday, August 25, 2004 2:10 PM -0700 Lisa Dusseault 
<[email-masked]> 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

Date: Wed, 25 Aug 2004 17:11:10 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Creating a calendar

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Data model issue
Date: Wed, 25 Aug 2004 14:10:43 -0700
To: Cyrus Daboo <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Wed, 25 Aug 2004 17:06:03 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Data model issue

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

Date: Mon, 23 Aug 2004 17:32:55 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] The VALARM problem

Hi Lisa,

--On Monday, August 23, 2004 1:45 PM -0700 Lisa Dusseault 
<[email-masked]> 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:
>
> <D:prop xmlns:D="DAV:">
>    <C:valarms xmlns:C="urn:ietf:params:xml:ns:calsch">
>
> <D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid52</D:
> href>
>
> <D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid58</D:
> href>
>    </C:valarms>
> </D:prop>
>
> 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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] The VALARM problem
Date: Mon, 23 Aug 2004 13:45:03 -0700
To: Cyrus Daboo <[email-masked]>
Cc: CalDAV DevList <[email-masked]>

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:

<D:prop xmlns:D="DAV:">
   <C:valarms xmlns:C="urn:ietf:params:xml:ns:calsch">
      
<D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid52</D: 
href>
      
<D:href>http://caldav.example.org/calendars/lisa/alarms/alarm_uid58</D: 
href>
   </C:valarms>
</D:prop>

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Lisa Dusseault <[email-masked]>
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 <[email-masked]>
Cc: [email-masked]

>
>>   - 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

Date: Mon, 23 Aug 2004 14:48:31 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] The VALARM problem

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

Date: Mon, 23 Aug 2004 12:14:26 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Client work?

Hi Helge,

--On Wednesday, August 11, 2004 3:13 PM +0000 Helge Hess 
<[email-masked]> 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

Date: Sat, 21 Aug 2004 12:40:17 -0400
From: Cyrus Daboo <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [Ietf-caldav] Additional required properties

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Date: Sat, 21 Aug 2004 18:38:03 +0200
To: CalDAV DevList <[email-masked]>

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

Date: Sat, 21 Aug 2004 12:18:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Cc: 

Hi Helge,

--On Saturday, August 21, 2004 2:42 AM +0200 Helge Hess 
<[email-masked]> 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

Date: Sat, 21 Aug 2004 12:01:08 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Cc: [email-masked]

Hi Lisa,

--On Friday, August 20, 2004 11:24 PM -0700 Lisa Dusseault 
<[email-masked]> 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
>
> <?xml version="1.0" encoding="utf-8"?>
>   <D:propfind xmlns:D="DAV:">
>     <D:prop>
>       <D:getetag/>
>     </D:prop>
>   </D:propfind>
>
> [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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Date: Fri, 20 Aug 2004 23:24:40 -0700
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]

--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

<?xml version="1.0" encoding="utf-8"?>
   <D:propfind xmlns:D="DAV:">
     <D:prop>
       <D:getetag/>
     </D:prop>
   </D:propfind>

[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

<excerpt>

<excerpt>  - Attach conversations to events

</excerpt>

What are 'conversations' in this context?

</excerpt>

A pretty fuzzy Chandler concept -- just assume it's a fair amount of
text, possibly a fair bit larger than the iCalendar data itself.

<excerpt>

<excerpt>  - Keep very old events around --> keep very large calendars

</excerpt>

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.

</excerpt>

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.

<excerpt>

<excerpt>  - Good multi-author coordination changing different events,
or even

changing different properties of same event --> shared calendars like

meeting rooms

</excerpt>

This is presumably an issue with lock contention when sharing a
calendar?

</excerpt>

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.)

<excerpt>

<excerpt>  - Fast browsing to "what's on this user's calendar today"

</excerpt>

A report can easily handle that for either model.

</excerpt>

Why redefine what PROPFIND already does in the multi-resource model? 
I'd rather minimize the new things we need to design.

<excerpt>

<excerpt>  - Selective permissions

</excerpt>

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.

</excerpt>

It wouldn't be required for all clients, but it's certainly a Chandler
use case.

<excerpt>

<excerpt>IOW, I think it is in fact simple, but too simplistic.

<excerpt>We could consider another way to accomplish the client
simplicity you

</excerpt>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.

</excerpt>

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?

</excerpt>

Don't forget that a PROPFIND can get a named property -- like the ETag
-- for every item in a collection.  Here's how:

<fontfamily><param>Courier CE</param>C-->S

PROPFIND /repository/lisa/calendar/ HTTP/1.1

Depth: 1

Content-type: text/xml

<<?xml version="1.0" encoding="utf-8"?>

  <<D:propfind xmlns:D="DAV:">

    <<D:prop>

      <<D:getetag/>

    <</D:prop>

  <</D:propfind></fontfamily>

[Now client compares the resulting list of ETags/URLs to the table of
locally stored ETags/URLs.  For each new ETag, pipeline:]

<fontfamily><param>Courier CE</param>C-->S

GET /repository/lisa/calendar/new-event-on-server HTTP/1.1

</fontfamily>

[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:]

<fontfamily><param>Courier CE</param>C-->S

PUT /repository/lisa/calendar/new-event-on-client HTTP/1.1

...

</fontfamily>

[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.

<excerpt>

(*) 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

</excerpt>
--Apple-Mail-3-945647020--

Date: Fri, 20 Aug 2004 23:34:17 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Cc: 

Hi Tim,

--On Friday, August 20, 2004 11:15 PM -0400 [email-masked] 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

Date: Fri, 20 Aug 2004 23:15:44 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-caldav] Alternative to splitting out components

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. 

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Date: Sat, 21 Aug 2004 02:42:17 +0200
To: CalDAV DevList <[email-masked]>

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Date: Sat, 21 Aug 2004 02:18:46 +0200
To: CalDAV DevList <[email-masked]>

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

Date: Fri, 20 Aug 2004 19:51:45 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Cc: [email-masked]

Hi Lisa,

--On Friday, August 20, 2004 3:18 PM -0700 Lisa Dusseault 
<[email-masked]> 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

Date: Fri, 20 Aug 2004 16:18:37 -0700
From: Elias Sinderson <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Reply-To: [email-masked]

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Alternative to splitting out components
Date: Fri, 20 Aug 2004 15:18:48 -0700
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]

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  
> <http://www.ietf.org/internet-drafts/draft-dusseault-http-patch 
> -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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Fri, 20 Aug 2004 16:57:26 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-caldav] Alternative to splitting out components

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 
<http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-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

To: CalDAV DevList <[email-masked]>
From: Helge Hess <[email-masked]>
Date: Wed, 18 Aug 2004 22:53:35 +0200
Subject: [Ietf-caldav] CalDAV Notes

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:
        <resourcetype xmlns="DAV">
          <collection/>
          <C:calendar-container xmlns:C="urn:ietf:params:xml:ns:calsch">
        </resourcetype>
   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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] polling
Date: Wed, 18 Aug 2004 10:01:35 -0700
To: Dan Winship <[email-masked]>
Cc: [email-masked]

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] polling
Date: Wed, 18 Aug 2004 18:18:54 +0200
To: Dan Winship <[email-masked]>
Cc: [email-masked]

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

Subject: Re: [Ietf-caldav] polling
From: Dan Winship <[email-masked]>
To: Helge Hess <[email-masked]>
Date: Wed, 18 Aug 2004 10:09:05 -0400
Cc: [email-masked]

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Re:  RSS for calendar exchange /polling / etc.
Date: Wed, 18 Aug 2004 14:05:28 +0200
To: [email-masked]
Cc: [email-masked]

On Aug 18, 2004, at 5:01, [email-masked] 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

Date: Tue, 17 Aug 2004 23:01:28 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-caldav] Re:  RSS for calendar exchange /polling / etc.

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. 

From: "Bill Kearney" <[email-masked]>
Cc: <[email-masked]>
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

> 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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] polling
Date: Tue, 17 Aug 2004 23:32:21 +0200
To: Dan Winship <[email-masked]>
Cc: [email-masked]

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] Fwd: [Dev] RSS for calendar exchange?!
Date: Tue, 17 Aug 2004 23:06:31 +0200
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] polling
Date: Tue, 17 Aug 2004 11:48:17 -0700
To: Dan Winship <[email-masked]>
Cc: [email-masked]

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
>
>

Subject: Re: [Ietf-caldav] polling
From: Dan Winship <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Date: Tue, 17 Aug 2004 14:41:46 -0400
Cc: [email-masked]

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

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Tue, 17 Aug 2004 11:34:49 -0700
Subject: [Ietf-caldav] Fwd: [Dev] RSS for calendar exchange?!

--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 <[email-masked]>
> Date: August 17, 2004 10:53:08 AM PDT
> To: OSAF Development <[email-masked]>
> 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:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Ted Leung <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>August
17, 2004 10:53:08 AM PDT

<bold><color><param>0000,0000,0000</param>To: </color></bold>OSAF
Development <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Subject: </color>[Dev] RSS
for calendar exchange?!

</bold>

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

</excerpt>
--Apple-Mail-13-643855752--

From: Lisa Dusseault <[email-masked]>
Date: Tue, 17 Aug 2004 10:21:51 -0700
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: [Ietf-caldav] Re: [Ietf-calsify] Calsify list vs. CalDAV list?

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, [email-masked] 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] polling
Date: Tue, 17 Aug 2004 10:04:29 -0700
To: Dan Winship <[email-masked]>
Cc: [email-masked]

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

From: Dan Winship <[email-masked]>
To: [email-masked]
Date: Tue, 17 Aug 2004 12:33:46 -0400
Subject: [Ietf-caldav] polling

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

Date: Mon, 16 Aug 2004 20:34:44 -0400
To: [email-masked], [email-masked]
From: [email-masked]
Cc: 
Subject: [Ietf-caldav] Calsify list vs. CalDAV list?

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.  

From: Helge Hess <[email-masked]>
Date: Mon, 16 Aug 2004 23:51:43 +0200
To: Dan Winship <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] Re: Notifications [was Re: Client work]

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Re: Notifications [was Re: Client work]
Date: Mon, 16 Aug 2004 14:36:22 -0700
To: Dan Winship <[email-masked]>
Cc: [email-masked]

>
> 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

From: Dan Winship <[email-masked]>
To: Helge Hess <[email-masked]>
Date: Mon, 16 Aug 2004 17:22:50 -0400
Cc: [email-masked]
Subject: [Ietf-caldav] Re: Notifications [was Re: Client work]

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

From: Helge Hess <[email-masked]>
Date: Mon, 16 Aug 2004 23:18:31 +0200
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] Re: Notifications [was Re: Client work]

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

From: Lisa Dusseault <[email-masked]>
Date: Mon, 16 Aug 2004 13:29:23 -0700
To: Helge Hess <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] Re: Notifications [was Re: Client work]

> 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

From: Helge Hess <[email-masked]>
Date: Mon, 16 Aug 2004 22:27:21 +0200
To: Dan Winship <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] Re: Notifications [was Re: Client work]

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Client work?
Date: Mon, 16 Aug 2004 13:23:15 -0700
To: Helge Hess <[email-masked]>
Cc: Stuart Parmenter <[email-masked]>, Sheila Mooney <[email-masked]>, [email-masked]

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
>

From: Dan Winship <[email-masked]>
To: Helge Hess <[email-masked]>
Date: Mon, 16 Aug 2004 11:42:31 -0400
Cc: [email-masked]
Subject: [Ietf-caldav] Re: Notifications [was Re: Client work]

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

Date: Sat, 14 Aug 2004 12:59:16 -0600
From: Joe Hildebrand <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-caldav] Notifications [was Re: Client work]
Cc: [email-masked]
Reply-To: Joe Hildebrand <[email-masked]>

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 <[email-masked]> wrote:
> On Fri, 13 Aug 2004 09:06:24 -0700, Lisa Dusseault
> <[email-masked]> 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Client work?
Date: Sat, 14 Aug 2004 19:29:24 +0200
To: Lisa Dusseault <[email-masked]>
Cc: Stuart Parmenter <[email-masked]>, Sheila Mooney <[email-masked]>, [email-masked]

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

From: Helge Hess <[email-masked]>
Date: Sat, 14 Aug 2004 16:31:04 +0200
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] Re: Notifications [was Re: Client work]

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Client work?
Date: Fri, 13 Aug 2004 10:14:31 -0700
To: Helge Hess <[email-masked]>
Cc: Stuart Parmenter <[email-masked]>, Sheila Mooney <[email-masked]>, [email-masked]

>> 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

Date: Fri, 13 Aug 2004 12:57:50 -0400
From: Mike Shaver <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] Notifications [was Re: Client work]
Cc: [email-masked]
Reply-To: [email-masked]

On Fri, 13 Aug 2004 09:06:24 -0700, Lisa Dusseault
<[email-masked]> 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

From: Lisa Dusseault <[email-masked]>
Date: Fri, 13 Aug 2004 09:06:24 -0700
To: Dan Winship <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-caldav] Notifications [was Re: Client work]

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
>
>

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Client work?
Date: Fri, 13 Aug 2004 16:38:38 +0200
To: Dan Winship <[email-masked]>
Cc: [email-masked]

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

Subject: Re: [Ietf-caldav] CalDAV Client work?
From: Dan Winship <[email-masked]>
To: Helge Hess <[email-masked]>
Date: Fri, 13 Aug 2004 10:26:36 -0400
Cc: [email-masked]

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Client work?
Date: Fri, 13 Aug 2004 01:56:23 +0200
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-caldav] CalDAV Client work?
Date: Thu, 12 Aug 2004 12:46:40 -0700
To: Helge Hess <[email-masked]>
Cc: [email-masked]

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

To: [email-masked]
From: Helge Hess <[email-masked]>
Date: Thu, 12 Aug 2004 00:13:06 +0200
Subject: [Ietf-caldav] CalDAV Client work?

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