Subject: Users and calendars in CAP

From: Alexander Taler <[email-masked]>
Date: Fri, 23 Apr 1999 19:07:27 -0400

Hi All,

I've realised a mistake that we've been making.  A calid is _not_ a
caladdress.  CAP commands work on calendars, not on caladdresses /
users / principals.  This is what distinguishes CAP commands from iTIP
commands, and as a consequence of this they are governed by a
different security model than iTIP commands.  iTIP commands are
governed by the security model described in [ITIP]: only the
"ORGANIZER" can modify an event, except that "ATTENDEES" can delegate,
indicate participation status, etc.  On the other hand, CAP commands
are governed by access rights described in "VCAR" components in the
calendar store.

Paul Hill pointed out that:
> two tasks that all customers will
> expect to be able to perform, given the current text of the documents. The
> first task is, "I am me, let me modify calendars that I already know
> about." The second task is, "I am me, let me invite (or whatever) this
> other person without knowing the details of what the real calid is.

The second task is already handled by iTIP and iMIP, I create a
VEVENT, with an appropriate ATTENDEE property, and I mail it to the
person.  It is a lot easier to get an email address than a calid.

The first task is the purpose of CAP, I want to be able to manipulate
my calendar, create new events, delete ones I am not interested in,
change or add properties to existing events, etc.

The only trick is to get CAP to perform the second task, since I don't
want to email people whose calendars are stored on the same server as
mine.  The obvious way to do this is to incorporate iTIP into CAP.

CAP should have two sets of methods, the first being iTIP methods
which use caladdresses, the second being CAP methods which use calids.
With this partition it is easy to manipulate calendars ignoring the
iTIP request-reply paradigm, by using calids and the CAP methods.  It is
also easy to request meetings and check busy time, ignoring the issues
of which calendars to use, by using caladdresses and the iTIP methods.

This also addresses some of the questions of fanout.  If CAP fanout is
not available, iTIP fanout can still be used over iRIP or iMIP, and
since CAP uses the iTIP methods themselves, there is no problem of
translation.

Of course the relationship between calids and a caladdresses still has
to be described of course.  A good place to start on this problem is
Paul Hill's observations on the problem.

This also has implications for how authentication is handled.  I will
follow this issue in another post.

Alex

---

From: John Stracke <[email-masked]>
Date: Mon, 26 Apr 1999 15:12:02 +0000

Alexander Taler wrote:

> mine.

Or whose calendars your server can access via iRIP.

> The obvious way to do this is to incorporate iTIP into CAP.

I'm not sure we want to incorporate it; a better approach might be to have CUAs
implement both CAP and iRIP.  That way we avoid the complications of defining
yet another transport binding for iTIP.

On the other hand, there is certainly some advantage to having CAP-like and
iTIP-like functionality occur over the same TCP link.  Perhaps CAP could be an
extension of iRIP?

--
/=============================================================\
|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 |
\=============================================================/