Subject: How to use CAP for scheduling events.

From: Alexander Taler <[email-masked]>
Date: Mon, 24 May 1999 15:13:14 -0400

People will use CAP both to store events in their own
calendars and to invite other users to events.  There is a
conceptual distinction between these two activities, the
first is a direct manipulation of a data store, and the
second is the initiation of a scheduling work-flow.  This
conceptual distinction divides the things which CAP will be
used for into two distinct groups, namely, calendar store
access activities and scheduling work-flow activities.

It is not obvious that CAP needs to have a control model
which respects this distinction; it is possible to implement
scheduling functionality using calendar store access
functionality.  However, CAP has a lot to gain by respecting
this distinction and having two distinct control sets.  I
believe that trying to perform scheduling activities using
calendar access functionality will result in problems for
the protocol and implementations; problems which will not
occur if scheduling controls are also provided in CAP.

I am advocating a Scheduling Model for CAP, which
incorporates iTIP methods into CAP.  In this model, in a
single CAP session I can use both iTIP methods such as
REQUEST, REPLY, and COUNTER, and CAP methods such as CREATE,
DELETE, and MODIFY.  I would use the CREATE method when
copying information from a website to my own calendar, but
the REQUEST command when inviting friends to dinner.

This model can be contrasted with the Direct Access model
which only provides the CAP direct calendar access methods
such as CREATE, DELETE and MODIFY.  In this model scheduling
activities are performed using these methods.

In the Scheduling model, an iTIP method would not
necessarily result in information being written directly to
a calendar, since the recipient may not want it there.
Instead, a calendaring inbox would exist on the server into
which iTIP commands would go.  The recipient would check
this inbox and, if they wished, update their calendar using
CAP methods such as CREATE, MODIFY, etc.  A CS
implementation could also allow information from the inbox
to be added directly to the calendar under certain
circumstances, for example if directed booking were
configured.

In the Direct Access model scheduling would be done through
direct access to the calendar.  Inviting another person to a
meeting is done with the CAP CREATE method which creates a
meeting directly in their calendar.  They then check their
calendar, and decide whether or not they wish to attend this
new meeting.  Their acceptance is indicated by modifying the
entry in their calendar and, presumably, by modifying the
entry in my calendar too.  I then see that they have
accepted the meeting and take any actions based on this,
such as changing the meeting status from tentative to
confirmed, and propogate these changes back to their
calendar.

A trite analogy in favour of the Scheduling model is to
think of the difference between sending someone a letter to
invite them to dinner, versus writing it directly into their
diary.

The following more complicated example highlights the
problems that I see with the Direct Access model.  I do not
think that these problems are insurmountable, just that they
are unnecessary complications for the protocol and
implementations.

I invite someone to a meeting by writing it directly to
their calendar, however, the details have errors which they
want me to fix (an iTIP COUNTER).  They cannot do this by
modifying my calendar store, since I have not given them
write permissions to this event (except for their
participation status).  So they must do this by modifying
their own version.  By regularly polling their calendar I
pick up the changes they made and interpret them as a
COUNTER, realise my mistake and fix my own copy.  They then
notice that I have updated my copy through their regular
polling, and consequently accept the event.  Having accepted
the event, they want to make sure they don't forget it, so
they place an alarm in the event, and add "COMMENT" property
reminding them not to forget the printouts.  I notice these
changes but I ignore them because I realise that they are
just local changes, not a COUNTER.  Later I have to delay
the meeting and change some of its details.  When I
propagate the changes to their calendar I have to be careful
not to modify the alarms or other properties that they have
added (unless they figured out a way to stop me with VCARs).

In favour of the Scheduling model, its adoption is not a lot
of work.  The protocol work can be taken from iTIP.  CUA
implementations are likely to already have iMIP and iTIP
incorporated, and CSs will only have to implement an inbox,
or integrate with their iRIP implementation.  However,
adopting the Direct Access model will be a lot more work,
since the new paradigm will have to be defined in the
protocol, and implementations will have to have significant
extensions.

Among the work necessary for using the Direct Access model
is the setting up of a complicated series of access rights.
To have scheduling access on a calendar you will need
permission to create new events in that calendar, but only
if you are the Organizer.  You will have to be able to
modify these events, but not properties that you didn't put
there, not the "ORGANIZER" property, and not the
participation status of that Attendee.  I would also want to
deny you permission to write alarms, since they can be
irritating and dangerous (procedural).

The use of the Scheduling model allows other features, such
as a CS triggering actions based upon scheduling activities.
For instance, my CS may page me when I get a new invitation
or a cancel, but I don't want to be paged when my friend
copies the hockey schedule to my calendar or my team members
update the delivery dates for our product.

---

From: John Stracke <[email-masked]>
Date: Mon, 24 May 1999 21:13:10 +0000

Alexander Taler wrote:

> DELETE, and MODIFY.

I think this is a good direction.  Then we could redefine iRIP to be
"CAP without CREATE/DELETE/MODIFY", which would eliminate redundancy and
reduce the amount of work needed to finish the specs and to implement
them.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: Alexander Taler <[email-masked]>
Date: Sun, 30 May 1999 13:43:19 -0400

The already developed scheduling protocols consist of a
transport independent protocol along with transport
bindings.  Perhaps this is a good approach to take with CAP.
The transport independent part would describe just the
calendar access methods, ignoring iTIP scheduling methods.
One real-time binding could then be developed which supports
both the calendar access and scheduling methods.  If partial
support is permitted then implementations could just support
one set of the methods.

Alex