Subject: A Special Place In CAP

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

Steve Mansour wrote:

>On a related topic, I have been working on the assumption that from CAP's
point
>of view, in order to invite or book a person to an event or to-do the same
>approach is followed. That is, we specify precisely the Relative CalUID(s)
on
>which the iCal components are to be stored.
>
>I bring this up because there have been several discussions about having a
CAP
>server store all incoming requests/bookings in a special place associated
with
>a user, not with a calendar.

"Oh, isn't that special!"

By this "special" place I assume you mean an input queue on the CS. This
sounds like we are talking about an implementation detail. I think you
would probably agree that this is not germaine.

I thought that you were going to take this thread in a different direction.
That is, the discussion around "fanout". Didn't we have general agreement
that a CS doesn't do any fanout, right? If you want to schedule an
appointment on a number of calendars, then you would have to transmit the
iTIP method, using CAP, to each of the calendars. Specifying multiple
ATTENDEE properties in the iCalendar object doesn't have the "side effect"
of getting the appointment scheduled on each of the ATTENDEE's calendars.
Instead, to do this, you need to specify the CalIDs for each of the
ATTENDEEs on a TARGET property (or whatever it is called) in the iCalendar
object specified in the SENDDATA CAP command to the CS.

-- Frank

---

From: [email-masked] (Steve Mansour)
Date: Wed, 19 May 1999 09:22:09 -0700

> would probably agree that this is not germaine.

I recall that discussion, but that's not the one to which I was referring.

-Steve