Re: [Ietf-caldav] Calendar collections

["G. Barnes" <[e-mail]>]

On Thu, 25 Aug 2005, Lisa Dusseault wrote:

> 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

As I said, I'm not suggesting the existing data model be changed.
You list some of the good reasons why it is the way it is.

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

I made one concrete suggestion.  I think the 2nd paragraph in 4.6.1 should
be changed:

    Support for MKCALENDAR on the server is OPTIONAL because some
    calendar stores only support one calendar per user (or principal) and
    those are typically pre-created for each account.  However, servers
    and clients are strongly encouraged to support MKCALENDAR whenever
    possible to allow users to create multiple calendar collections to
    better help organize their data.

First of all, there's the obvious problem that this paragraph says
OPTIONAL (equivalent to MAY), when Section 2 says SHOULD.

More importantly for this discussion:  if you agree that CalDAV 
is not necessarily in the business of defining a user
model, then the justification that MKCALENDAR 'allows users to create
multiple calendar collections to better organize their data' should
not be used, as it closely links the DAV collections model and the user
model.

I originally suggested that the SHOULD (from section 2) be changed into
a MAY.  Upon further reflection, I suspect there are probably good reasons
why we want to encourage support of MKCALENDAR, such as that it
allows *clients* to create calendar collections when appropriate --- if
we're going to force clients to create a coherent user model out of the
WebDAV collections model, we should give them all the tools we can.  So
I withdraw any preference for SHOULD vs. MAY/OPTIONAL, as long as the
justification in the last sentence is changed to make it clear that
this method is for the benefit of CalDAV clients, not the end users.

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

I could easily change the example so that it works within
the university setting, where it's easy to imagine most or all of the 
calendars reside on the same server.  But even if you only consider private 
events, partitioning is not easy or, I think, particularly desirable.  If 
there's a retirement party for my co-worker Joe next Friday during regular 
work hours, do I stick that in my 'social' calendar, or my 'work' calendar? 
This goes back to my filing example.  I can divide most of my stuff into 
neat little categories, but some of it belongs in more than one.

                   Greg Barnes
                   Computing and Communications, University of Washington
                   [e-mail]
                   [phone]

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