Re: [Ietf-caldav] Calendar collections

[Lisa Dusseault <[e-mail]>]

You're both entirely correct, but collections are rather a necessity 
for many existing architectures.  Some of what you need or want 
collections for:
  - must have for PROPFIND -- partition entire space of events into 
reasonable-to-PROPFIND chunks
  - nice to have for managing quota (proposed quota properties on 
collections)
  - nice to have (or must on some servers) for managing access control 
-- can grant "read" access to Mike on my calendar via the calendar 
collection
  - collections inside user accounts provide guidance for ownership -- 
who should be able to control content as last resort
  - the standard, required way URLs are constructed in WebDAV

Recall that addresses and the structure of addresses  are both somewhat 
fixed and somewhat arbitrary.  The REPORTs we have so far go a certain 
way towards treating calendar data like it resides in one big component 
soup without arbitrary collections -- e.g. if you put a bunch of 
sports-related calendars, each in an individual collection, all inside 
one parent collection, and support calendar REPORT on the parent 
collection, then a REPORT lets me see events across all those calendars 
with certain filters.

What else can a server do beyond CalDAV and collections?
  - In addition to the structured, collection namespace, the server 
could offer a "soup" namespace -- for example a way to retrieve each 
event by some unique identifier: 
"http://caldav.example.org/uuid/6ba7b814-9dad-11d1-80b4-00c04fd430c8"
  - The server could support additional REPORT or SEARCH tools to allow 
arbitrary access across the repository.

What else can a client do?
  - A client like Apple's iCal is entirely possible - I can subscribe to 
Mike's calendar on Mike's server and Greg's calendar on Greg's server, 
and overlay those calendars with my own (hosted at a third server)
  - A personal calendar client could (and arguably should) put all "my" 
events into a single calendar.  It could also create a second calendar 
only if I, the user, explicitly wanted a separate set of people to 
share a separate set of events with -- a rare, power-user function.
  - A calendar client managing public event calendars could (and 
arguably should) group events for several organizations or venues into 
one CalDAV "calendar" collection and tag those events according to 
venue and group. E.g. the "543 Howard St office" calendar could include 
events for the Gotham, Lilliput and Whoville meeting rooms and for 
OSAF, KEI and Creative Commons organizations -- all in one collection.
  - A calendar client subscribing to public event calendars could browse 
the "543 Howard St office" calendar and then decide only to display (if 
this were the user's choice) those meetings that were tagged with the 
OSAF organization[1]

These are basically examples of what Greg suggests -- that the basic 
CalDAV data model isn't at all the final answer for the client's 
calendar model or the mental model it creates for users.

Mike, I'm quite sensitive to the comparison to email (we're struggling 
with that with IMAP support in Chandler).  But unless we had or 
designed a new collection-free repository access protocol (or morphed 
WebDAV into one) we're kind of stuck with collections.  I welcome any 
suggestions that help ensure that the protocol data model isn't forced 
into user's faces any more than it has to be.

Finally, Greg, part of the problem you describe with different calendar 
owners wanting a piece of the same public event is inherent not just in 
WebDAV but in the federated nature of successful content systems on the 
Internet.  Today if I want to publicize a band's concert I do so on my 
own Web blog even if that band has it's own web site and the concert 
hall has its own web site too.  If you send me an email you probably 
retain a copy on your server as well as the copy (or copies) I retain 
on my server.  I don't think that single-instancing public content is a 
problem that we can or want to fix -- and I apologize if this turns out 
to be a straw man.

Lisa

Footnote 1: I'm hand-waving over the standardization of events tagged 
with organization affiliations or machine-readable locations, because 
we haven't addressed standardizing public calendars --  we're focused 
on individual calendar use cases in CalDAV 1.0.

On Aug 25, 2005, at 8:05 AM, Mike Shaver wrote:

> On 8/25/05, G. Barnes <[e-mail]> wrote:
>> This discussion reinforces my belief that the data model of CalDAV
>> calendar collections probably should not be used as the data model one
>> presents to users.
>>
>> Although this is never stated explicitly in the draft, it appears to
>> me that the underlying CalDAV model is one where calendar collections
>> partition the universe of events.  I'm sure there are valid reasons
>> for this model, so I'm certainly not going to say it should be 
>> changed.
>>
>> However, there is a danger when you try to make your users' model 
>> match
>> this model.  That is, I think most people who use calendaring systems
>> will agree that a 'calendar' is a useful thing to think about.  But
>> if you try to make 'calendars' equivalent to CalDAV calendar 
>> collections,
>> you're going to run into problems.
>
> Yes, yes, yes.  This is basically what happened with every thick mail
> client built in the 90s: it was a faithful reflection of the server's
> folder hierarchy -- or, for many users, the hierarchies of multiple
> servers.  In the calendar case we already have a large body of
> evidence indicating that users will aggregate many different calendars
> into their views of the world, and partitioning them along
> server-storage lines is not something that I think we should be
> "baking into" recommendations like the CalDAV spec.
>
> Mike