Subject: Re: Use of "Scheduling Inbox" & search

From: Doug Royer <[email-masked]>
Date: Fri, 25 Jun 1999 11:40:09 -0700 (PDT)

Lisa,

FYI: When we discussed this being submitted in Montreal we were made aware
that in order to make the cap-00 draft we had to have it in sooner. As the
deadline for submitting the draft to the IETF is today.

The draft as sent around (you got a copy) to the authors / editors
to quick check for errors did not include the text you have below.

It does not mean it will not be discussed. This email does however
mean it did not make our deadline for submission to the IETF
for cap-00.

-Doug

> From: "Lisa Lippert \(Dusseault\) \(Platinum\)" <[email-masked]>
> To: <[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.

---

From: Doug Royer <[email-masked]>
Date: Tue, 29 Jun 1999 09:49:43 -0700 (PDT)

> ......  I was asked to write up the search part of this in more detail for
> discussion on the list.

And thank you.

> 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.

Not an issue.  The VCAR model allows this with both models.  Simply
allow them access with the methods you want.  The VCAR would be the
same.  If there are physically two tables, then you need two copies of
the VCAR.  One in the inbox, the other in the calendar.

By the definition in CAP-00 you do not have access unless specifically
granted access.  Here is the GRANT portion of a VCAR you might use:

  GRANT;UPN=all;ACTION=create;OBJECT=METHOD:REQUEST

>  - Cleaner addressing:  calendaring methods MUST be targetted at a store
> location, whereas scheduling methods MAY be targetted at user addresses
> such as mailto: addresses.

I don't understand why this is in this list.  I can send you an iMIP
message to your email address.  Your implementation may save it in the
message store, might auto-process it, might auto-transfer it into the
CS for the user.

How does that effect the model?  It will still need to be stored
somewhere until the user acts on the REQUEST. Both models assume
some way to know that its an scheduling method and not a booked
entry. Why does the calendar address scheme used by the sending
user effect the model?

>  - 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).

True - But again, this does not effect the model. They simply
say NO to any METHOD they do not want to handle. Same is true
for both methods. 

>  - 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.

I strongly believe that breaking CAP into separate documents will only
slow it down.  Cap-00 was written.  It address calendaring and
scheduling.  We are just debating the draft.  That's part of its life
cycle.

> 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.

True - the only change to what we discussed is the exact query
string sent to the CS and just a few small changes

> 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.

This works both ways.

And I argue that having to perform two separate queries to
find the current state of a components is not making the
life of the CUA easier.

> 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.

I think we discussed the automatic agents as user agents making
decisions. They can't just transfer the items into a calendar. If they
did, then all CUA's would have to process scheduling requests both in
the calendar and in a separate queue. If they had to process
them in the calendar as well - why have both?

Which brings up another point: What if an existing component
changed to NEEDS-ACTION. You now have two queries.

> 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.

CREATE, DELETE, and MODIFY are already defined in CAP-00.

> 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

  We had discussed that the METHOD stored in the schema
  would be CREATE for booked events. So the DELETE or MODIFY are
  not needed.
  
					  SELECT * FROM * WHERE METHOD=CREATE
					    	
> 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

  Because booked events are stored as CREATE, and there is no
  such METHOD as CANCEL (its a STATUS parameter for an event),
  it would be:
  
  					SELECT * FROM * WHERE METHOD != CREATE

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

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

				       SELECT * FROM VEVENT WHERE METHOD=CREATE
				       
> 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)                               UID=foo

(I assume you meant UID not CALID).

				       SELECT * FROM * WHERE METHOD=CREATE
				       AND UID=foo

However I think this is dangerous as what the CUA will really want
is the latest status of the component. So I think the CUA will
need to get every METHOD and process any updates. So I think
the QUERY will need to be:

				      SELECT * FROM * WHERE UID=foo
	
Now the CUA has everything it needs to process any updates to
the UID.
			      
> Get all items   SELECT * FROM CAL,SCHED   SELECT * FROM VEVENT
> relating to     WHERE CALID=foo           WHERE CALID=foo
> particular 
> event,
> including new
> requests

(Again I think you meant UID not CALID)

				    SELECT * FROM VEVENT WHERE UID=foo

You did not mention one that I think will be common:

Get all components
that have a PARTSTAT
of NEEDS-ACTION

	SLECT * FROM CAL,SCHED			SELECT * FROM VEVENT,VTODO
	WHERE PARTSTAT=NEEDS-ACTION		WHERE PARTSTAT=NEEDS-ACTION
	AND (xxx=VEVENT or xxx=VTODO)

       ([xxx] not shure how I can only search
       VTODO or VEVENTS in your model)
	
> Summary:  I think that the separate scope model makes client queries
> much simpler. 

That could be debated. The CUA is going to have to ask
for scheduling updates to events, or what the user sees may
be out of date. With two queries, you have increased the 
round trip time that may have an effect on low bandwidth connections.

-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