Subject: 1.3 Defintions: BOOKED

From: [email-masked]
Date: Wed, 30 Oct 2002 14:26:28 -0500

The 09-b-2 draft says:

   BOOKED -  xxx An entry in the calendar store has one of three
      conceptual states.  It is "UNPROCESSED" state, "BOOKED" state or
      marked as "DELETED" state.  How the implementation stores the
      state of any object is not a protocol issues and is not discussed.
      An object can be said to be booked, unprocessed, or marked for
      delete.

First, the "xxx" after the dash should be removed.

Second, the term 'entry' is used to denote those components like VEVENTs 
or VTODOs instead of using 'entity' which denotes all objects including 
VTIMEZONEs, VCARs, etc.  There is no actual definition of what an 'entry' 
actually is.  There is text under Section 2.2 that says:

   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)

We may want to create an explicit definition as to what a Calendar Entry 
is versus a Calendar Entity since we use the terms freely but not do not 
explicitly define them (see above).  This could allow some folks to 
interpret the distinction incorrectly.   To seed the distinction I would 
define entry explicitly as VEVENTs, VTODOs or VJOURNALs only and be done 
w/it.  We cant just say "Any [RFC2445] defined components" because that 
would include VTIMEZONEs, VFREEBUSYs and VALARMs."

Editorial:  The text:

      1.  A "UNPROCESSED" state scheduling entry...

should start with "An" instead of "A".

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

Editorial suggestion:  The text:

      2.  A booked entry is stored with the "CREATE" command.

should be tweaked to be like the following for consistancy:

      2.  A "BOOKED" state entry is stored with the "CREATE" command.

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.

After all you do not put deleted VCARs or VTIMEZONEs into a "DELETED" 
state do you?  Along w/this change you probably should change the 
references of "deleted object" to "deleted entry" in that paragraph.

If you opt not to make this change you need to change "DELETE" to 
"DELETED" at least.

On the topic of querying for deleted entries, we should clearly state 
(preferably in 1.3) that no actual data is guaranteed to be returned for a 
"DELETED" entry with maybe the exception of the UID (maybe...).  Otherwise 
we get into the rat hole of specifying tombstoning, etc.  Id prefer we 
just clearly state that a CUA can query for DELETED entries and the CS can 
return some data but whats returned is not specified or guaranteed.

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: Wed, 30 Oct 2002 13:10:55 -0700

> would include VTIMEZONEs, VFREEBUSYs and VALARMs."

Again - what's the problem? It is true.

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Oct 2002 13:09:58 -0700

[email-masked] wrote:

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

What's the problem?

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Oct 2002 13:12:32 -0700

> state do you?

Why not?

-- 
-
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: Doug Royer <[email-masked]>
Date: Wed, 30 Oct 2002 13:18:34 -0700

> (preferably in 1.3) that no actual data is guaranteed to be returned for 
> a "DELETED" entry with maybe the exception of the UID (maybe...). 
>  Otherwise we get into the rat hole of specifying tombstoning, etc.  Id 
> prefer we just clearly state that a CUA can query for DELETED entries 
> and the CS can return some data but whats returned is not specified or 
> guarantee.

No, that won't work. Other reasons for the DELETED state are:

	Detection of duplicate iTIP messages
  		Your going to have to keep the entire object in
		order to detect if it is a duplicate.

	Ignoring events for which you do not wish to attend.
		If you keep getting a REQUEST for a meeting,
		you can mark it as DELETED and then ignore any
		updates. In some cases you will want to remain
		on the distribution list, even if you are not
		going to attend a specific instance.

AND
	I do not recall this WG discussing ANY options that would
	allow the CS or CUA to remove anything from the marked for
	deleted objects.

	The only change to the object is it state.

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Oct 2002 12:04:46 -0700

> First, the "xxx" after the dash should be removed.

Done.

> VTIMEZONEs, VCARs, etc.  There is no actual definition of what an 
> 'entry' actually is.  There is text under Section 2.2 that says:

I changed it to use the word 'object', to be consistent with the
rest of CAP:

      An object in the calendar store ....

> considered "BOOKED".  (Same goes for a VQUERY, VTIMEZONE, etc)

Yes - they are booked.

> should start with "An" instead of "A".

Done.

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

   All object with a "METHOD" property are [iTIP] objects.

>       2.  A "BOOKED" state entry is stored with the "CREATE" command.

Done.

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