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

From: Doug Royer <[email-masked]>
Date: Mon, 24 May 1999 13:55:14 -0700 (PDT)

> Date: Mon, 24 May 1999 15:13:14 -0400
> From: Alexander Taler <[email-masked]>
> 
> ...
> 
> I am advocating a Scheduling Model for CAP, which
> incorporates iTIP methods into CAP.  In this model, in a
> single CAP session I can use both iTIP methods such as
> REQUEST, REPLY, and COUNTER, and CAP methods such as CREATE,
> DELETE, and MODIFY.  I would use the CREATE method when
> copying information from a website to my own calendar, but
> the REQUEST command when inviting friends to dinner.
>
> ...

I also think that CAP MUST be able to use all iTIP messages.
However it may have to add to the data in order for the CS
to understand how to apply the object as iTIP is unauthenticated.
With a CUA and an authenticated user, the iTIP message may be
directly bookable. Where if it arrived via an unauthenticated
route - it may go in to some kind of implementation queue for
later intervention by a user or process. So via a CUA the
iTIP message would be its iTIP meaning PLUS - use the authenticated
users access.

However I may or might not want to have an 'inbox'. I see that
as an implementation detail.

If the implementation allows iTIP methods to directly book - let it.

If another implementation does not allow this, it can:

	a) Reject them.

	b) Save them for later intervention by whatever method
	   the implementation desires (inbox, queue, ...).

-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: John Stracke <[email-masked]>
Date: Mon, 24 May 1999 21:29:11 +0000

Doug Royer wrote:

> So via a CUA the

Makes perfect sense.  From 2446 (iTIP):

     The transport protocol will be responsible for providing
     facilities for authentication and encryption using standard
     Internet mechanisms that are mutually understood between the
     sender and receiver.

I agree that the inbox would not impact interop.

--
/=============================================================\
|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: Alexander Taler <[email-masked]>
Date: Mon, 24 May 1999 19:07:23 -0400

> as an implementation detail.

I am not sure how an inbox could be an implementation detail.  I
understand an inbox as a place where the CS stores scheduling messages
which the CUA can download.  Since this is a CUA - CS interaction it
must be in the protocol.

> If another implementation does not allow this, it can:

If a CS can reject iTIP methods then the CUA will fallback to what I
called the Direct Access model, in which case we have gained nothing.

Alex