[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Use of "Scheduling Inbox" & search
> From: "Lisa Lippert \(Dusseault\) \(Platinum\)" <email@example.com>
> Date: Fri, 25 Jun 1999 11:15:49 -0700
> At the CAP authors meeting in Montreal, the protocol breakout group
> ...... 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
> - 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
> - 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:
> - 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
> 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
> 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
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
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
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
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
> Get all items SELECT * FROM CAL,SCHED SELECT * FROM VEVENT
> relating to WHERE CALID=foo WHERE CALID=foo
> including new
(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
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.
801 W. El Camino #131 Work: (650)786-7599
Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL