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

From: Doug Royer <[email-masked]>
Date: Mon, 24 May 1999 16:52:37 -0700 (PDT)

> Date: Mon, 24 May 1999 19:18:49 -0400
> From: Alexander Taler <[email-masked]>
> 
> Frank Dawson/CAM/Lotus wrote:
> > Doug's comments about authorization can be addressed by adding the iTIP
> > methods to the "ACTION" enumerations in the "GRANT" and "DENY" properties
> > in the VCAR component.
> 
> I think that Doug was more concerned with the fact that iTIP
> may come over insecure, unauthenticated routes, such as mail,
> or perhaps a connection to the calendar server which was
> authenticated as anonymous.  In these cases the judgement (or 
> culpability) of a person would be required before changes 
> could be made to the data store.  This means that some sort 
> of inbox or queue would be required, at least for 
> unauthenticated messages.

Frank is correct - I meant that there are two authentication issues
when an iTIP message is processed by a CS. Both can be addressed
by a VCAR.

> > 
> > The need for the inbox/outbox for dequeueing/queueing iTIP messages is
> > probably an implementation specific design. I am not certain that it is a
> > conceptual necessity. Certainly with iTIP/iMIP, there is no requirement for
> > an inbox/outbox for handling iTIP messages. Likewise, I don't see this
> > necessitating any model changes for CAP.
> 
> On the contrary, an inbox is mandatory to support iTIP COUNTERs.  
> The Organizer has to make a conscious decision before accepting
> a COUNTER.

That does not mean that my implementation must queue the request by
storing it in an INBOX.  In fact I plan on allowing (via VCAR access)
direct booking of requests.  They will show up as such and allow the
user to see them in the calendar exactly the same way as Frank
described. Viewable - not however committed.

There are installed instances of this same implementation where direct
booking would not be desirable - a public internet accessible CS may
want to implement an INBOX or queue.  I don't think we can force that
all requests must be queued.  Its up to the implementation to
determine how the request is stored.  As long as it follows the same
iTIP semantics as the calendar user expects who issued the iTIP request.

One CS implementation may direct book all requests. No INBOX needed.

One CS implementation may queue it for a user to REPLY yes or no at a
later time.  Some sort of queuing needed - perhaps in the Calendar
itself.  Perhaps an INBOX.

Another may reject it in the same way a user would do if they
had an INBOX and said 'no I do not want that one in my calendar'.
No INBOX or queue needed as it will never be accepted unless
via-direct-CUA + authenticated user CAP request.

All will interoperate as the APPLICATION level object protocol (iCal+iTIP)
has not changed.

-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: Alexander Taler <[email-masked]>
Date: Mon, 24 May 1999 20:09:15 -0400

> All will interoperate as the APPLICATION level object protocol (iCal+iTIP)

Point taken, an Inbox is not mandatory for an implementation, as
the CS can make decisions whether or not to accept iTIP messages.

However, I feel that there is a need for an inbox at the 
protocol level.  If CAP incorporates iTIP, then it must support
COUNTERs.  Clearly COUNTERs cannot be automatically accepted, 
so they must go somewhere else.  That somewhere else has to
be accessible to whichever CUA I use, and therefore has to
be in CAP.

In the cases that you mention, where my CS doesn't actually
store anything in an inbox, queries to the inbox will always
report that it is empty.

Alex