Subject: Re: How to use CAP for scheduling events.

From: Frank Dawson/CAM/Lotus <[email-masked]>
Date: Mon, 24 May 1999 21:55:44 GMT

I agree that CAP should be able to be used for transferring iTIP methods.
Doug Royer clearly indicates a basis for why we may need to extend the
"restriction tables" used in RFC 2446 (i.e., the iTIP specification). We
will clearly need to add both the TARGET and CMDID properties to an "iTIP
PLUS" method that was sent over a CAP connection.

Doug's comments about authorization can be addressed by adding the iTIP
methods to the "ACTION" enumerations in the "GRANT" and "DENY" properties
in the VCAR component.

The need for the inbox/outbox for dequeueing/queueing iTIP messages is
probably an implementation specific design. I am not certain that it is a
conceptual necessity. Certainly with iTIP/iMIP, there is no requirement for
an inbox/outbox for handling iTIP messages. Likewise, I don't see this
necessitating any model changes for CAP.

Using iTIP methods for CAP scheduling has many advantages. For example, I
can restrict calendar access to calendar manipulation functions such as
CREATE, READ, MODIFY, UPDATE, DELETE; but can allow calendar user to
"invite" me to meeting by granting REQUEST action access and also allow a
calendar user to "respond to invitations" that I send them by granting
REPLY action access. This also applies for the other iTIP scheduling
methods.

I believe that receipt of an iTIP-PLUS "VEVENT type of REQUEST" method by a
CAP CS will involve putting the event component on my calendar. I would
also expect that my participation status (i.e., the PART-STATUS parameter
on my ATTENDEE property) would be "NEEDS-ACTION". This would allow me to
query my calendar for events needing my response. When I send a "VEVENT
type of REPLY" method to the Organizer's calendar, then I would expect
that, given I have "GRANT:PRINCIPAL=fdawson;ACTION=REPLY;OBJECT=VEVENT"
calendar access rights on this calendar, the CAP command would update my
PART-STATUS parameter on my ATTENDEE property in the correct VEVENT. Sounds
straight forward and simple. Mega cool!

Separating CAP capabilities into "Calendar Manipulation" and "Calendar
Scheduling" makes alot of sense. Good idea Alex!

-- Frank

---

From: Alexander Taler <[email-masked]>
Date: Mon, 24 May 1999 19:18:49 -0400

> methods to the "ACTION" enumerations in the "GRANT" and "DENY" properties

I think that Doug was more concerned with the fact that iTIP
may come over insecure, unauthenticated routes, such as mail,
or perhaps a connection to the calendar server which was
authenticated as anonymous.  In these cases the judgement (or 
culpability) of a person would be required before changes 
could be made to the data store.  This means that some sort 
of inbox or queue would be required, at least for 
unauthenticated messages.

> necessitating any model changes for CAP.

On the contrary, an inbox is mandatory to support iTIP COUNTERs.  
The Organizer has to make a conscious decision before accepting
a COUNTER.