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

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

Doug:

Another side-effect of allowing "iTIP Plus" methods in CAP is that we now
have closed a very sticky relationship hole we had in our protocol model.
That is, we had a clear relationship between iCalendar, iTIP and the two
bindings (i.e., iMIP and iRIP). What we lacked was the relationship between
iRIP and CAP.

Was the relationship between iRIP and CAP similar to that between POP and
IMAP. By allowing iTIP-Plus methods in CAP, we might be able to
characterize iRIP as a functional subset of CAP. Maybe even a conformance
class to CAP? Sounds very appealing to me.

NOTE: By iTIP-Plus, I mean that we update within CAP the iTIP restriction
tables to include the CAP specific iCalendar extensions and where these
properties and parameters are used in each of the iTIP-Plus methods.

-- Frank

---

From: "Peter O'Leary" <[email-masked]>
Date: Tue, 25 May 1999 15:36:19 -0700

Gang,

Before we start congratulating ourselves overmuch, allow me to make a
counter-proposal:

iTIP and CAP should have NOTHING in common. CAP should be concerned ONLY
with creating, modifying and deleting events, not with inviting others to an
event or otherwise propogating event information. Remember, iTIP and its
derivatives were intended to be "interoperability" protocols, while CAP was
intended to allow clients to access to servers. The relationship between the
two protocols would therefore be more along the lines of SMTP and IMAP, not
POP and IMAP.

I think one fallacy here is thinking that all calendaring operations involve
inviting other people to events. Put another way: I can imagine someone
implementing CAP to allow storing/updating/deleting calendar events on a
server and NOT implementing iTIP.

Another tendancy I see in this proposal is "as long as I've got the port
open, I might as well...". Let's not put iTIP commands through CAP just
because it's convenient.

Pete.