Subject: Re: problems with CAP not having "users" and hierarchical calendars

From: David Madeo <[email-masked]>
Date: Wed, 19 May 1999 07:57:53 -0400

Since we seem to have everyone's attention... [please read the earlier mails,
I'm jumping right back in on a reply from Doug to Paul]

> > Should there be a CAP operation that can be used to determine which
> > calendars I own?
>
> Yes - ask for all calendars where the OWNER property contains
> your authenticated id.

Without trying to confuse the issue, there's a distinction between the
Calendars I manage, and the calendars that represent my personal schedule.

> > Now George just wants to determine when Alice is available for a meeting.
>
> > Does George have to discover the entire calendar hierarchy and then query
>
> > each calendar to determine if Alice has an appointment in it? Obviously
> > this would be very inefficient.
>
> So is BUSY time a query to the CS or query to a calendar on a CS?

It's both, as you go into below.

> If it were a CS query - then how would I ask for a specific calendar only?
>
> What if I want the calendar BUSY time, and not a authenticated id busy
> time?
> (Is this room available - I do not care who else has it at other times).
>
> Perhaps:
>
>         If I provide only the CSID and a username, I would
>         be asking for any BUSY time for the username
>         for any calendar on the CS.

>         If I provide a RELCALID and a username, I would be
>         asking for any BUSY time for the username and only
>         for that calendar.
>
>         If I provide a RELCALID and NO username, I would be
>         asking for any BUSY time on the calendar.
>
>         I don't think that asking for BUSY time for all users
>         on a CS has any use.

I really really like these distinctions.  I agree with the three categories,
but I disagree on what the answer should be when I ask for busy time of a
CSID and a username. Rather than specify that it should be "any Busy time for
the username for any calendar on the CS", I'd want it to be a standard
iCalendar formatted freebusy answer, discovered in an implementation specific
way in response to a standard protocol query.

A simple implementation would give you the union of all events.  A better
implementation that I might choose out of the many would allow the user to
pick which components will show up in response to a query of their personal
busy time.  We need to distinguish between events that prevent me from being
somewhere else and events I own, but have no intention of ever showing up
at.  That's not to say it's not marked as "busy".  Perhaps I have a sub
calendar with my turnover schedule.  I'm only allowed to have one turnover
per day.

> > The key thing I'm trying to push is that we should make the protocol
> simple
> > and provide flexibility for the server implementation.  If we say that
> CAP
> > has to provide (subject to authorization) the busy times of dmadeo when
> > asked to, then by hiding the details of whether that's many calendars or
> > one, we've simplified the protocol without limiting the implementors.
>
> Agreed.

Good, Paul and Doug and I all agree.  Anyone else have a feeling on this?

> > Another user appears to use multiple calendars to help keep track of
> > overlapping appointments - knowing that he will not attend 'this one'
> this
> > week. I his case he does not want "rollup" to be a mandatory feature. A
> > counter argument to the previous statement is that VEVENTs within a
> > calendar may overlap and the user should simply modify the attendance on
> > the event that will be skipped during a particular week. Should we extend
>
> > iCalendar to include a property for "allow conflicts"?
>
> Yes - I think by default conflicts should be allowed.
> And I think that each component or calendar should be allowed
> to be marked 'no conflicts' and enforced by the CS.

Since I believe I'm the user being quoted, I agree as well.  How does one
extend iCalendar without opening up the can of worms?

> Another issue with appointments is, as Frank pointed out:
>
>         That meeting is 15 minutes away, so I am also busy
>         15 minutes before and 15 minutes after that appointment.
>
> In which case the CUA better not tweak with the component. The time
> block would have to be local to the users calendar and not pushed
> back to the ORGANIZER as an update to the component. And it may or
> might not be visible as a component in a query, yet be OPAQUE
> and show up as BUSY.

This is probably a CS implementation issue.  Every time an event is created,
automatically create two events on either side of it.

This is crossing even further into cultural/personal work habits, but not
every meeting needs this buffer.  There's a huge difference between  two
meetings scheduled back to back, in the same room versus different buildings
a few city blocks apart.  Which leads me believe it should be a new sort of
action in a VALARM component.  This event, I want an email, for that event I
want a display 15 minutes beforehand and a 10 min buffer on both sides since
it's a five minute walk away.

> I see hierarchical calendars and roll-up as separate.
>
> And I see that roll-up as a calendar option listing the CALIDs
> of any calendar - sub-calendar or not.
>
> I could live with roll-up not in CAP-1.

If we don't discuss rollup, then we're still left with the question of "how
does George figure out when Alice is busy".    Querying for all events owned
by Alice isn't right.  I humbly submit that CAP-1 needs to address this
somehow, whether it's a simple rollup query, or identifying a default
calendar , or some clever thing that no one has brought up yet.

dmadeo

---

From: Frank Dawson/CAM/Lotus <[email-masked]>
Date: Wed, 19 May 1999 14:16:40 GMT

David:

A calendar user is outside the scope, so to speak, of an electronic
protocol. What the protocol can manipulate is a backend store and protocol
states.

Hence, a busy time request needs to be specific to a calendar. Because what
it is really asking for is the snapshot (i.e., a rendering of a period of
time in terms of FREEBUSY property values) of the lack of availability on a
calendar for a period of time.

The complexity of finding busy time for a calendar user that may use more
than one calendar is not simplified by asking a calendar server for busy
time for a given calendar user. I may be a co-owner for a calendar for my
child's T-ball (a youth baseball sport), but this is certainly not one of
the calendars that I use to schedule my time. The notion of which calendars
I use to reflect my activity is something that seems to be a property that
I would keep in my directory. Very similar to the notion of which of my
dozen or so email addresses are appropriate for you to send email to.

Hence, it would be more appropriate in our CAP discussions to point to the
use of the "locate" specification as a basis for the vCard and LDAP server
properties that we should be using to specify which CalIDs are to be used
to schedule with me, access my published busy time, get a snapshot of my
calendar, and point a CAP compliant CUA at.

- - Frank

---

From: Frank Dawson/CAM/Lotus <[email-masked]>
Date: Wed, 19 May 1999 14:17:45 GMT

David:

PS...If you want to know my busy time via CAP, then send a
REQUEST/VFREEBUSY iTIP method over CAP to my CAPURL, as specified in my
vCard ;-)

- - Frank