Subject: free-busy QUERY

From: "Craig Johnson" <[email-masked]>
Date: Wed, 23 Jul 2003 17:43:05 -0600

Doug Proposed:
 
> So for clarity, I am proposing that for CSs that do support
> 'RECUR EXPAND' and do support "VFREEBUSY":
>
>     QUERY: SELECT * FROM VFREEBUSY
>      WHERE dtstart >= start range
>      AND dtend <= enduring
 
The query does not work in the following cases:  
It excludes vfreebusys(vevents) that overlap the start of the period of
interest (ie that start before startrange and end after startrange).
It excludes vfreebusys(vevents) that overlap the end of the period of
interest (ie that start before endrange and end after endrange).
Try this:
 
    WHERE dtstart < endrange
    AND   dtend   > startrange
 
>   The value of STATE is irrelevant as they are only created
>   dynamically. And if STATE is supplied it MUST be ignored.
 
Unless I missed something, that severly cripples iTIP VFREEBUSY.  
How is a CUA supposed to retrieve unprocessed iTIP VFREEBUSY objects if
STATE is now ignored?  The following will no longer work:
 
     QUERY: Select * from VFREEBUSY
      WHERE STATE() = 'unprocessed'
 
Instead of returning iTIP VFREEBUSYs the above query returns
dynamically generated VFREEBUSYs ... ALL of them.
I may want to retrieve iTIP VFREEBUSY objects from a VAGENDA for a
specific time period.  The query would look very similar to the first
query above:
 
      QUERY: SELECT * FROM VFREEBUSY
       WHERE dtstart < endrange
       AND   dtend   > startrange
       AND   STATE() = 'unprocessed'
 
However, because STATE is ignored I will get a dynamic VFREEBUSYs and
not the iTIP VFREEBUSYs I wanted.
 
I understand your eagerness to simplify the free-busy QUERY, but I'm
not convinced you can omit STATE for VFREEBUSY.  Maybe you have
something else in mind.  Please avoid 'special case' handling of
VFREEBUSY and STATE just to keep it simple.  Let's keep it consistent
with the syntax for other components (VEVENTS, etc.)

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Jul 2003 09:34:03 -0600

> interest (ie that start before endrange and end after endrange).

Thanks.

> STATE is now ignored?  The following will no longer work:

Because they are useless for CSs that support EXPAND-RECUR. No point
in saving them or fetching them. If the CS is to dynamically create
the results, who would ever fetch the static ones? Why?

> Instead of returning iTIP VFREEBUSYs the above query returns dynamically 
> generated VFREEBUSYs ... ALL of them.

How would you ever use the static VFREEBUSY's?

-- 

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

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Thu, 24 Jul 2003 11:44:36 -0400

>     AND   dtend   > startrange

Yep, thats the correct formula.  Extra credit to those (besides Craig) who 
can demonstrate why...

> How is a CUA supposed to retrieve unprocessed iTIP VFREEBUSY objects
> if STATE is now ignored?  The following will no longer work:
> 

Umm, VFREEBUSYs should be generated to reflect the _other_ contents of the 
TARGETed calendar (VAGENDA).  They do NOT have any 'state' of their own. 
You do not set the VFREEBUSYs state to 'booked', 'deleted', etc. as thats 
just non-sensensical.

Do not confuse that with the iTIP REQUEST/REPLY workflow where busytime is 
asked for and returned.  The difference is that recipients of the 
VFREEBUSY data do no treat it like a REPLY for a VEVENT that needs to be 
reflected in the Organizers 'booked' copy, they treat the busytime data as 
information useful in performing scheduling with other users.  The 
Organizer does not 'process' the VFREEBUSY by doing actions like doing 
DECLINE-COUNTER or modifying their copy to reflect delegation, etc; they 
simply use the data then and there.

As such STATE() is a meaningless factor on the QUERY when VFREEBUSYs are 
involved.  The data inside the VFREEBUSY response is essentially a summary 
of the ATTENDEEs free/busy time, it represents an extraction of data from 
other components in the calendar.  In fact nearly ALL of the cap-factor 
nodes in the ABNF are non-sensical for VFREEBUSYs (what the hell does "NOT 
LIKE" mean in this context??). 

I do agree w/Doug that meaningless query factors MUST be ignored but there 
is NO prose in 6.1.1.  CAL-QUERY Value Type to this effect.  I think some 
prose is definitely in order on this topic.  A simple line or two like 
"Any query factor that is in error or meaningless MUST be ignored.   For 
example, using STATE() = "fizbin" or DTEND LIKE "TODAY" should result in 
that query factor being ignored.".  The only question that remains then is 
does the CS indicate this in some way to the CUA and if so, how??

Now some may argue that the Organzier may want to preserve the VFREEBUSY 
data for later use (kind of like reading but not 'processing' a REPLY to 
an event).  However this is not reasonable behaviour in a real-time 
environment.  The VFREEBUSY data may be stale by that later time.  In a 
real-time system like CAP the Organzier should perform another VFREEBUSY 
search so they get the most accurate busytime picture for the invitees as 
possible.

> dynamically generated VFREEBUSYs ... ALL of them.

VFREEBUSYs should always be dynamically generated in my view of things but 
some folks do not share that opinion.  Thats fine by me.  Ive owned the 
busytime system in Lotus Notes for 5+ years now so I think I have a feel 
for how well this works and how a CS can do it efficiently.

Generating static VFREEBUSYs is viable for some cases but since the 
generator cannot guarantee that their staticlly generated VFREEBUSYs will 
exactly match the intervals requested there are 2 possible options: The CS 
manually trims down or joins multiple static VFREEBUSYs into a single 
response that matches the requested interval OR the CUA is expected to 
take all the VFREEBUSY data that the CS sends, sift thru it to find what 
it wants and toss what it does not want.  This can be done but its either 
extra cycles for the CS (former case) or its lots of wasted network 
bandwidth and CUA cycles (latter case).  The latter case is also a concern 
for those thin client fans out there...

> However, because STATE is ignored I will get a dynamic VFREEBUSYs 
> and not the iTIP VFREEBUSYs I wanted.

Ahh, now I see your case better: You want to get both the dynamic CS 
genreated VFREEBUSY data for the specific interval AND the iMIP VFREEBUSY 
REPLYs that the CUA may have sent out all in 1 operation. 

If any CUA actually did busytime lookups over iMIP I could agree to this 
scenario.  However so far not a single CUA at any CalConnect has 
demonstrated VFREEBUSY REQUEST/REPLY abilities over iMIP.  The reason Ive 
heard for this is that although it _can_ be done, the lag makes the 
response inherently useless to the Organzier when they are sitting in 
their calendar trying to schedule a meeting.  Users want immediate 
responses for busytime, not some unknown lag inherent in iMIP.

Does anyone know of any CUAs that actually do VFREEBUSY REQUEST/REPLY? 
Please speak up now so we can decide if this is a viable case to factor 
into the CAP design.  I suspect it is not a scenario we need to consider 
though.   I  could see wanting to keep the ability in CAP to at least be 
able to find and remove these from the users queue so whats the way to go 
on this...

FWIW: CAP appears to be divergent from iTIP in doing VFREEBUSY 
REQUEST/REPLYs given what Ive read so far in these recent threads.  It 
seems that the current expectation is that the CUA would do a:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//ACME/DesktopCalendar//EN
   C: CMD:SEARCH
   C: TARGET:relcalB
   C: TARGET:relcalC
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VFREEBUSY
   C:  WHERE DTEND > '19990310T080000Z'
   C:  AND DTSTART < '19990310T190000Z'
   C: END:VQUERY
   C: END:VCALENDAR

but thats NOT the way iTIP describes how the REQUEST is done:

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VFREEBUSY
   ORGANIZER:Mailto:[email-masked]
   ATTENDEE:Mailto:[email-masked]
   ATTENDEE:Mailto:[email-masked]
   DTSTAMP:19990303T190000Z
   DTSTART:19990310T080000Z
   DTEND:19990310T190000Z
   UID:[email-masked]
   END:VFREEBUSY
   END:VCALENDAR

Its not clear to me the CS can properly generate an iTIP VFREEBUSY REPLY 
since A) there are NO iTIP required properties (ie: ATTENDEE, ORGANIZER or 
UID) and B) unlike other CAP commands where the payload is in iTIP format, 
the SEARCH command does lend its payload to being in iTIP, its in 
CAL-QUERY.  The SEARCH command is semantically what the user wants (they 
want to search for other users busytime) but it does not lend itself to 
doing busytime searches that are iTIP compliant.  Bit of a quandry. 
Hmmm...

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: Thu, 24 Jul 2003 10:17:36 -0600

> genreated VFREEBUSY data for the specific interval AND the iMIP 
> VFREEBUSY REPLYs that the CUA may have sent out all in 1 operation.  
> 
> demonstrated VFREEBUSY REQUEST/REPLY abilities over iMIP.  The reason 
> Ive heard for this is that although it _can_ be done, the lag makes the 
> able to find and remove these from the users queue so whats the way to 
> go on this...

And as the CS is not an iMIP aware MUA it would not be its job to worry
about any iMIP objects. The CUA if acting as an iMIP agent can generate
any iMIP replies from the results it gets back from the CS.

--