Subject: Use of "Scheduling Inbox" & search

From: "Lisa Lippert \(Dusseault\) \(Platinum\)" <[email-masked]>
Date: Fri, 25 Jun 1999 11:15:49 -0700

At the CAP authors meeting in Montreal, the protocol breakout group
discussed a conceptual "Scheduling Inbox".  This would be a virtual or
real store location where new scheduling requests received over iTIP can
be stored.  These iTIP requests can be delivered via iMIP (if the
receiving email client or email server knows to deposit the iTIP
messages in this location), or potentially over CSTP (Calendaring &
Scheduling Transport Protocol, which we've been suggesting could be the
basis for both CAP and for real-time support for iTIP).  I was asked to
write up the search part of this in more detail for discussion on the
list.

Overview of Separation Model
----------------------------

This proposed model separates "calendaring components", or items that
show up on the calendar and have been in some way accepted, from
"scheduling components", or items which have been submitted to the
calendar or user but which have not yet been accepted.  
 - Example of a "calendaring component":  A VTODO component with no iTIP
method associated would conceptually be in my calendar, because it's not
a request -- it's an actual appointment, directly booked by some user or
agent.  
 - Example of a "scheduling component":  A VTODO component with a method
of REQUEST arrives (somehow), and no user or agent has reviewed it.
Before it gets reviewed (and booked, declined or countered), the request
will not appear in my calendar, but instead appears in the user's
"scheduling inbox" (although it may be stored anywhere on the server).  

Advantages of this model:  It makes many common scenarios easier to
handle.  
 - Access control: if I want to allow somebody to send me schedule
requests but not write directly to my calendar, I can simply allow them
write access to my "scheduling inbox" only.  If I want to allow somebody
to view my calendar, but not view requests that I haven't dealt with
yet, I can simply allow them read access to my calendar only, and not my
scheduling inbox.
 - Cleaner addressing:  calendaring methods MUST be targetted at a store
location, whereas scheduling methods MAY be targetted at user addresses
such as mailto: addresses.
 - Implementations can support part of all functionality.  E.g. a free
calendar access service may wish to implement only the calendaring
components and operations, and require clients to handle scheduling on
their own (as they do today).
 - Dave Crocker pointed out that this may allow us to get quicker
progress on getting the simpler pieces of functionality approved in the
IETF, IF we ever choose to break the functionality up into separate
documents we have that option.

We went through a number of step-by-step scenarios (e.g. receiving and
accepting a VTODO REQUEST, receiving and declining a VTODO REQUEST...)
and verified that this model can be consistently followed by clients.
These scenarios are available in the notes.

We all agreed that this model is conceptual only, that the underlying
store can legitimately store calendaring and scheduling items together
as long as the protocol works as defined.  The separation is for
simplification of the protocol and of client operations, not an
implementation requirement.

Also, we all agreed that this model does not prevent an implementation
from having some kind of automatic agent that can immediately deal with
items in the "scheduling inbox", perhaps transferring requests directly
to the calendar.  Indeed, we think automatic agents operate well in this
model because there is a clear bucket of items for the agent to act on.

QUERIES on calendaring vs. scheduling components
------------------------------------------------

We discussed a couple ways of querying for components in this model.  I
proposed a new virtual location or "scope" (this is a SQL concept) that
can be used in the FROM clause of a SQL query.  I call the scope "SCHED"
for the scheduling inbox, and the scope for calendaring components is
"CAL"  (I don't really care what the names are, these are just
suggestions).  (This makes more sense to me than putting VEVENT or VTODO
in the FROM clause, because the component type can be easily queried in
the WHERE clause.)

Doug proposed that both virtual locations have the same conceptual
scope, and instead the WHERE clause be used instead to distinguish
whether the user wants calendaring components, scheduling components, or
both.  Theoretically, the WHERE clause can be used because the METHOD
property could be defined to have different values for the different
kinds of components we're trying to separate.  This requires us to add
methods for the kinds of things we're doing for calendar access, such as
CREATE, DELETE and MODIFY.

In this mail, I'm going to try to offer examples from both proposals,
even though Doug may want to correct me if I misunderstood him, because
it seemed useful to me to compare them side-by-side for the same
operations.

Operation       Separate scopes           Same scope
-----------------------------------------------------------------------
Get list of     SELECT * FROM CAL         SELECT * FROM VEVENT, VTODO,

items I've                                VJOURNAL WHERE METHOD=CREATE  
accepted                                  OR METHOD=DELETE OR
or written                                METHOD=MODIFY

Get list of     SELECT * FROM SCHED       SELECT * FROM VEVENT, VTODO,
pending                                   VJOURNAL WHERE METHOD=REQUEST
requests                                  OR METHOD=PUBLISH OR
                                          METHOD=COUNTER OR
                                          METHOD=REPLY OR
                                          METHOD=CANCEL

Get everything  SELECT * FROM CAL,        SELECT * FROM VEVENT, VTODO,
                SCHED                     VJOURNAL

Get items on    SELECT * FROM CAL         SELECT * FROM VEVENT WHERE
my calendar     WHERE TYPE=VEVENT         METHOD=CREATE OR
(appointments)                            METHOD=DELETE OR
                                          METHOD=MODIFY

Get particular  SELECT * FROM CAL         SELECT * FROM VEVENT WHERE
accepted event  WHERE CALID=foo           (METHOD=CREATE OR 
(not new                                  METHOD=DELETE OR
request for                               METHOD=MODIFY) AND
same event)                               CALID=foo

Get all items   SELECT * FROM CAL,SCHED   SELECT * FROM VEVENT
relating to     WHERE CALID=foo           WHERE CALID=foo
particular 
event,
including new
requests

Summary:  I think that the separate scope model makes client queries
much simpler. 

Lisa

---

From: John Stracke <[email-masked]>
Date: Sun, 27 Jun 1999 14:35:36 +0000

> Summary:  I think that the separate scope model makes client queries

I agree.  It will also simplify server implementation, because it makes
the inbox more explicit.  A server can easily distinguish between
separate scopes in the FROM clause, and use them to optimize its backend
search.  Without separate scopes, a server which implements the inbox
separately would have to parse the query's WHERE clause carefully to
figure out which scope(s) it applied to.

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