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

From: John Stracke <[email-masked]>
Date: Tue, 01 Jun 1999 16:32:20 +0000

Peter O'Leary wrote:

> >
> > So if I create a VEVENT using CAP that looks EXACTLY like an iTIP method:
> > You are saying it should not work exactly like iTIP?
>
> I think there is a running assumption that CAP will be derived from iTIP.
> Why is this the case?

Because, if CAP performs any iTIP-like functions, it is most parsimonious, and
hence most efficient (in terms of time spent on the spec, time spent on
implementation, and probably performance) for it to use iTIP.

As for your suggestion that CAP *not* perform iTIP-like functions, I think it's
risky; a calendar client talking to a CS will necessarily require iTIP
functionality, and we don't want to have two separate connections.

However, there is one part of your suggestion that I like: making CAP
transport-independent.  In this case, we would define iTIP extensions (yielding
iTIP+), and state that iTIP+ can be carried over any transport that can carry
iTIP (yielding iMIP+ and iRIP+).  CAP would then be equivalent to iRIP+.

(The + names are a placeholder, an easy way of getting the point across; I
don't actually propose that we use 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: Doug Royer <[email-masked]>
Date: Tue, 1 Jun 1999 11:13:56 -0700 (PDT)

> From: "Peter O'Leary" <[email-masked]>
> Date: Thu, 27 May 1999 14:27:00 -0700
>
> >
> Why is this the case? Why can't CAP be another "transport" for iCalendar
> since the goal of CAP is not "interoperability", as it was with iTIP.

If not, then I could not drag-n-drop an iMIP message onto my CUA?
If they were not the same, then there would have to be a 1:1 mapping
between the new CAP object and an iTIP object - correct?
If so, then why create another one?

> Since we're defining the protocol, we can disallow iTIP objects from CAP,
> right?

No - I think this would just multiply the object count by at least two.
And it would add the complexity of having to map them back and forth
across the transports.

> I think CAP should be limited, for the sake of simplicity and clarity, to
> just a few basic operations: CREATE, MODIFY, DELETE. Let iTIP and it's
> derivitives be used for REQUEST, REPLY, COUNTER, etc.

Again - what if IO 'CREATE' an object that looks just like an iTIP
PUBLISH? Should I expect it to work just like an iTIP PUBLISH?

> > > 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.
> >
> > Yes it could be done. However it still would not stop  a CUA from
> > storing a VEVENT in the CS that looked like an iTIP method.
> 
> See above.

I do not see where you replied - or I don't understand something.

> > > 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.
> >
> > Not the reason. The user is going to expect to be able to schedule
> > in an authenticated way - iMIP does not give us that.
> >
> 
> iRIP does.

Yes - as far as iTIP takes scheduling. How do I get your access
to your calendar in an authenticated way? Not with iRIP.
How do you pass down calendar information, Access Lists, ... ?
iTIP does not handle these. Are you suggesting that iTIP be expanded
to include CAP? If yes - then what's the difference between
including iTIP in CAP, or CAP in iTIP?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Tue, 1 Jun 1999 15:00:55 -0700 (PDT)

> Date: Tue, 01 Jun 1999 17:03:09 -0400
> From: Alexander Taler <[email-masked]>
> > 
> > If someone iMIP's your a COUNTER to your EMAIL-ADDRESS. How
> > will you be inserting it into your CS? I think via CAP.
> 
> If someone sends me a counter via iMIP it goes into my 
> mail server from which I download it using whichever 
> protocol I prefer.  After cracking it open I figure out
> what it means and then apply changes to my calendar
> store as need be.

Did you assume the MTA could crack it open? Not going to
happen for security reasons - how would it open up secure
email (S/MIME, ...)?

Did you assume the MUA could crack it open? Not all CUAs and MUAs
will be the same binary. Even if the MUA could be configured to
know that it was a calendar object - the MUA might not know CAP.

If you meant that the CUA would crack it open - Using what protocol
would you apply the iTIP changes?  Not via iMIP or iTIP as not all
MTAs and MUA can deal with iCalendar objects.  That leaves CAP.  I
don't think that iRIP can do it as it will not be able to use/display
conflict information - other than busy time.  Other (anonymous?)
users is why busy time exists.  The calendar user will want to view
their calendar as they decide if they want to accept the COUNTER.
Then; accept and modify their calendar, or reject it (perhaps via
iMIP).

> When you CAP me an iTIP COUNTER, how do I get this from
> the calendar store? 

By looking for these kind of things using the CAP protocol.
We have not defined the specifics - perhaps it would be marked 
NEEDS-ACTION?

> Where and how in the calendar store is this information kept?

Wherever the yet to be defined query can find it. I don't think
it matters as long as the query returns the results needed.

I would say it could be located within the component object that it is
intended to COUNTER.  In this way all of the object related to any
component are self contained and transportable via any transport
including any requests, counter, ...  Now this is implementation
specifics.  However this is also a valid way to get the job done.

> I must be able to use
> CAP to retrieve this information from the calendar store,
> and it must not change any events in my calendar.

A NEEDS-ACTION event could be stored in your calendar - and
it need not effect anything else.

> I agree that how it is stored in my CUA is an 
> implementation detail, but how it travels from the CS
> to my CUA is not.

From the CS to the CUA - CAP.
From some random source (iMIP) to the CUA is not defined.
From the CUA to the CS - CAP.

I see iRIP as a great way to transport objects between servers.

-Doug

---

From: Frank_Dawson/CAM/[email-masked]
Date: Tue, 1 Jun 1999 21:17:16 -0400

Alex:

Some comments below.

-- Frank

>what it means and then apply changes to my calendar

I am assuming that the iMIP goes to the "Organizer" of an original REQUEST.
Right?

If the MIME entity containing the iCalendar/iMIP object is encrypted, you won't
even know it is a C&S message in the mail server. It will just be a
"multipart/encrypted" MIME entity. Your decryption keys are in the MUA, right?
So, won't the MUA have to hand it over to the CUA (assuming that they are not
integrated into an "ICE" style of application) _after_ first decrypting it? Are
you assuming that the MUA is CAP enabled and puts the counter into the
"Organizer" calendar? I don't know what form this "counter" would be in an
iCalendar based calendar.

I would have thought that the MUA would hand the counter message, after
decrypting it, over to the CUA for the CUA to process. The CUA gets instructions
to accept the counter (from the calendar user manipulating the CUA), in which
case the CUA uses CAP to update the property event (via correlation with the
UID/SEQUENCE/DTSTAMP) and possibly send out confirmations of the acceptance of
the counter via a rescheduling of the original event (see iTIP for explanation
of how COUNTER method is accepted). Or, the calendar user instructs the CUA that
it doesn't want to accept the counter, in which case the CUA will send a
DECLINECOUNTER iMIP message back to the "Attendee" originating the iMIP COUNTER
method.

Did I miss something? I don't see a problem here. No need for an INBOX/OUTBOX.

For further discussion: In an iCalendar native calendar, how would you represent
a the counter information that is contained in a COUNTER method. Do we need to
address this for "ICE" (Integrated Client Environements) where the MUA and CUA
are one application?

>the calendar store?  Where and how in the calendar
>store is this information kept?  I must be able to use

Agree that if iTIP methods are allowed in CAP, this needs to be specified. Isn't
this also the case for REFRESH methods? Or if I send your CS a REFRESH, will I
get a REQUEST back automatically from a CS-side agent? Suppose the calendar user
indicated in their CUA "usage profile" that they wanted to manually process all
REFRESH methods? This scenario does raise this issue. The above iMIP scenario
didn't help too much.

And what about an iTIP REPLY from an uninvited "Attendee"; the so-called "gate
crasher" scenario. How does the "gate crasher" make this request? If we only had
CAP functions (e.g., CREATE, READ, MODIFY, DELETE, etc.), then the calendar
access rights in the VCARs would surely prevent anyone from doing the equivalent
of issueing an unsolicited REPLY. I think it is cool that this requires
acceptance of iTIP messages in CAP. With the higher level calendar manipulation
functions alone, someone might not be able to perform this accepted action. Of
course, the recipient calendar might have a VCAR denying anyone from performing
an unsolicited "REPLY" anyway. What would that VCAR grammar look like ... 8-|
... hairy for sure!

>implementation detail, but how it travels from the CS

Indeed. This is the $1000 question. Maybe we do need to think about separate
calendar components for queueing inbound COUNTER, REFRESH and REPLY functions?