[Ietf-caldav] non-calendar resources in calendar collections

[Brian Moseley]

On 3/16/06, Bernard Desruisseaux <bernard.desruisseaux at oracle.com> wrote:

> A calendar object resource would be accessible via two URLs:
>
>     /home/brian/generic/mtg123.ics   -- regular collection
>     /home/brian/calendar/mtg123.ics  -- calendar collection
>
> and these two URLs would be mapped to the same resource in your
> internal store (you don't want to duplicate data).

that is technically possible, but it doesn't meet our requirement for
having a collection accessible by a single url :)

here's the "maximum interop, user friendly" chandler/cosmo sharing scenario:

1) user A shares a collection of data containing resource of many
types, including some of multiple types (for example, "all of my work
stuff") to cosmo, which responds with the url to the shared collection

2) user A sends that url to user B, another chandler user, who
subscribes to the shared collection using chandler's "smart"
capabilities, receiving all of the resources in the collection,
regardless of type

3) user A sends the same url to user C, an evolution user, who
subscribes to the shared collection using caldav, receiving just the
calendar resources (and multitype resources stamped as calendar
objects)

4) user A sends the same url to user D, an ical user, who subscribes
to the shared collection using "webcal", receiving a monolithic
icalendar object containing icalendar representations of all of the
calendar resources (and multitype resources stamped as calendar
objects)

we want a single cosmo collection to masquerade as a caldav calendar
collection for user  and as a webcal-style monolithic calendar
resource for user D, as well as operating as a "smart" collection for
chandler.

the caldav scenario is the only problematic one, since the caldav
client has no way to ask for just the calendar resources from the
collection. we have no way of distinguishing between a caldav client
and a "smart" client. using the Accept header would solve this
problem, no?