Subject: Re: 1.3 Defintions: BOOKED

From: [email-masked]
Date: Tue, 5 Nov 2002 11:32:16 -0500

Doug responded on 10/31/2002 02:04:46 PM:
> >    A CUA may create a "BOOKED" state entry by depositing a iCalendar
> >   object into the store.  This is done by depositing an object that
> >   does not have a "METHOD" property.
> > 
> > However this is not 100% accurate as a CUA can deposit a VCAR into the 

> > CS w/o a METHOD property and by this definition the VCAR would be 
> > considered "BOOKED".  (Same goes for a VQUERY, VTIMEZONE, etc)
> 
> Yes - they are booked.

Semantic meaning of 'booked' is being overloaded.  "BOOKED" has a workflow 
oriented semantic meaning; "I cant make 9:30AM, Im already booked then", 
"Sorry, all of our rooms are booked for that date.", etc.  For 
non-workflow components (VQUERY, VCAR, etc) there is NO matching semantic 
meaning that can be applied; "Im sorry, your booked Access Rights are 
insufficient to read that entry".

We can (and in fact are) overloading the semantic meaning of "BOOKED" and 
that is my objection.  Its not a ship stopper but its still an objection I 
wanted raised.

> > Editorial suggestion:  The text:
> > 
> >                                   All scheduled entries are
> >          [iTIP] objects.
>  >
> > should include the phrase "group" to be more accurate:
> > 
> >                                   All group scheduled entries are
> >          [iTIP] objects.
>  >
> > since I can schedule an event on my calendar w/o using iTIP (ie: I 
> > create a doctors appointment w/o using iTIP).
> 
> As I don't see  the distinction, (are not all ITIP object
> group scheduling objects?) How about:

The distinction is that I can create entries on my calendar that affect my 
schedule but have NO workflow involved.  I would insert a "Doctor Appt @ 
10:30AM - 11:15AM" on my calendar after getting off the phone w/them. 
There is no associated workflow.  In other words, PIM Calendaring is also 
part of Calendaring & Scheduling and those PIM objects are NOT iTIP 
objects.  They have no METHOD, there is no workflow involved.  Hence its 
not 'group scheduling'.   All iTIP objects are group scheduled entries but 
not "All scheduled entires" are iTIP objects.

> > the same kind of change goes for changing:
> > 
> >       3.  A marked for delete component is set to the "DELETE" state.
> > 
> > to something like:
> > 
> >       3.  A "DELETED" state entry has been marked for deletion or 
> > actually removed from the Calendar.
> 
> That would make it - not true.
> 
> I used:
> 
>     A "DELETED" state entry is created by sending a "DELETE" command
>     with the "OPTION" parameter value set to "MARK".

We will continue this actual vs marked for deletion discussion in a single 
thread so hold that thought...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Nov 2002 10:31:41 -0700

[email-masked] wrote:
> Semantic meaning of 'booked' is being overloaded.  "BOOKED" has a 
> workflow oriented semantic meaning; "I cant make 9:30AM, Im already 
> booked then", "Sorry, all of our rooms are booked for that date.", etc. 
>  For non-workflow components (VQUERY, VCAR, etc) there is NO matching 
> semantic meaning that can be applied; "Im sorry, your booked Access 
> Rights are insufficient to read that entry".
> 
> We can (and in fact are) overloading the semantic meaning of "BOOKED" 
> and that is my objection.  Its not a ship stopper but its still an 
> objection I wanted raised.

CAP is a protocol - within the CAP protocol - I do not see that
BOOLED is overloaded. The name "BOOKED" came from the Canada
meeting hosted by then CS&T, I just used the name from the meeting.

The fact is that the data is booked or not (BOOKED). Or it is an iTIP
object or not (UNPROCESSED). Or is it marked for delete or not (DELETED).
Those are the states of object in the CAP protocol.

> The distinction is that I can create entries on my calendar that affect 
> my schedule but have NO workflow involved.  I would insert a "Doctor 
> Appt @ 10:30AM - 11:15AM" on my calendar after getting off the phone 
> w/them.  There is no associated workflow.  In other words, PIM 
> Calendaring is also part of Calendaring & Scheduling and those PIM 
> objects are NOT iTIP objects.  They have no METHOD, there is no workflow 
> involved.  Hence its not 'group scheduling'.   All iTIP objects are 
> group scheduled entries but not "All scheduled entires" are iTIP objects.

I do not see that workflow has anything to do with it. That is a
CUA usage issue - not a CAP protocol issue.

Those PIM objects are ether non-iCalendar (a.k.a. out of scope),
or they are BOOKED objects. Ether way - I just do not follow why
the protocol would need to change to store (BOOK) them.

-- 
-
Doug Royer                       Work: (208)612-INET
[email-masked]                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

---

From: [email-masked]
Date: Tue, 5 Nov 2002 15:50:58 -0500

> Those are the states of object in the CAP protocol.

Let me try to put my original point in finer detail:

Applying a state of "BOOKED" to a non-scheduling component is illogical 
since its not contextually thought of that way in normal human 
grammar/language.  As such the conceptual states like BOOKED and DELETED 
do not normally apply to non-scheduling components like VCARs, VAGENDAs or 
VQUERYs.  These components just "are" or "are not" there; they are not 
involved with the normal workflow process between CUs.

So I wanted to clear up the overly broad definition of BOOKED and DELETED 
so that it was clear they referred to scheduling components.  For all 
other components the 'state' of them should just be "there" or "not 
there". 

There are bigger issues to deal with (Tombstones / soft-deletions!) so Ill 
just leave my concern as noted.  If some still want to think of every 
componenting having workflow oriented states then thats their choice to 
make...

> the protocol would need to change to store (BOOK) them.

PIM (aka Calendaring) is NOT out of scope of CAP.  I dont need to create 
any workflow message to create a doctor appointment on my calendar or to 
just block of some 'quiet work time' on my calendar do I???

My doctor appoinment is "BOOKED" but the VCARs I create on my calendar 
that I put the appointment onto are NOT "BOOKED" from a linguistic POV. 
They are from the current CAP POV and I think that its incorrect.  See 
above if necessary...

Related question: Why should the CS keep my deleted (nay, "marked for 
deletion" only) VCARs if they are no longer used?  They should just be 
removed (or possibly tombstoned if you want to do Sync later on...)

Bruce