Subject: Re: CAP & busytime?

From: [email-masked]
Date: Tue, 1 Apr 2003 11:43:30 -0500

Doug responsed on 03/31/2003 04:15:47 PM:
> > I may infer from the text under CREATE that I (or my CUA) must CREATE 
> > the VFREEBUSY for it to exist (see create-vreply and create-comp). 
> 
> Yes.

Umm, why should I (a CUA) be able to do that?  Having VFREEBUSY info 
unrepresentable of the actual calendar data makes it useless for its 
intended purpose. 

There is NO reasonable way that any CUA can update the VFREEBUSY info to 
reflect a new change short of rewritting it ALL over!  If you check the 
ABNF for VFREEBUSY you will see that it contains minimal info:

     freebusyc  = "BEGIN" ":" "VFREEBUSY" CRLF
                  fbprop
                  "END" ":" "VFREEBUSY" CRLF

     fbprop     = *(

                ; the following are optional,
                ; but MUST NOT occur more than once

                contact / dtstart / dtend / duration / dtstamp /
                organizer / uid / url /

                ; the following are optional,
                ; and MAY occur more than once

                attendee / comment / freebusy / rstatus / x-prop

                )

and certainly NOTHING that would allow a CUA to pick and choose which 
FREEBUSY property to change/remove/add.  As such ALL CUAs would have to 
totally rewrite the VFREEBUSY info each and every time.  Sounds really 
efficient, even for 'fat' clients.  Im sure PDAs have the horsepower and 
bandwidth to do this updating often too...

FYI: the UID property is NOT the UID of the 'related' entry in the 
FREEBUSY property, it is the UID matching the UID of the REQUEST.  It was 
put there for iTIP messaging only, NOT for associating the FREEBUSY 
property to a particular calendar entry!  Also there can be multiple 
FREEBUSY properties that are an amalgam of several entries (ie: Merge my 3 
back to back to back meetings into 1 FREEBUSY representative of the 
combined time slice) so its not valid to assume a 1 to 1 mapping in CAP.

> TRANSPARENT entries will also not show up in your VFREEBUSY.

Why not!? Recheck 2445, the ABNF for a FREEBUSY property is (minor text 
edits applied for alignment):

     freebusy   = "FREEBUSY" fbparam ":" fbvalue CRLF

     fbparam    = *(
                ; the following is optional,
                ; but MUST NOT occur more than once

                (";" fbtypeparam) /

                ; the following is optional,
                ; and MAY occur more than once

                (";" xparam)

                )

     fbtypeparam  = "FBTYPE" "=" 
                (
                "FREE" / 
                "BUSY" /
                "BUSY-UNAVAILABLE" /
                "BUSY-TENTATIVE" /
                x-name /                ; Some experimental iCalendar data 
type
                iana-token
                )

so its perfectly legal (and useful!) to send back "Im pencilled in from 
3-3:30 tomorrow" so that the requestor knows you have some thing 
'tentative' on your calendar already. 

BTW: CAP needs to add some prose to reflect the new values for TRANSP 
defined in Section 8.37 so that the fbparam properly conveys that 
TRANSParency status.

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: John Stracke <[email-masked]>
Date: Tue, 01 Apr 2003 12:27:20 -0500

[email-masked] wrote:

> Having VFREEBUSY info unrepresentable of the actual calendar data 
> makes it useless for its intended purpose. 

Actually, on reflection, I'm not sure that's so.  There could be 
calendar events that one doesn't want exposed in one's VFREEBUSY; having 
the CUA compile the VFREEBUSY instead of the CS allows us to separate 
mechanism and policy, and move the policy component down towards the user.

However, this is an edge case, and the costs seem pretty high.  Consider 
this: if VFREEBUSY is compiled by the CUA, is there only one per user? 
Neither possibility is very appealing.  If there are multiples, then 
someone trying to schedule an event in a particular period may have to 
fetch each VFREEBUSY that overlaps that period, and combinet hem.  If 
there's only one, then anybody trying to schedule with a user is going 
to get their *entire* VFREEBUSY, probably including all events from the 
time the VFREEBUSY was created until some arbitrary end date (there has 
to be an end date, because VFREEBUSY doesn't have repeats); that could 
be huge.

If the VFREEBUSY were compiled on the fly by the CS (which should be a 
fairly cheap operation), then the requesting CUA could specify the 
period of interest, and get just the data it needs.

-- 
/============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centive.com                   |
|Centive           |My opinions are my own.                  |
|============================================================|
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_                      |
\============================================================/

---

From: [email-masked]
Date: Tue, 1 Apr 2003 14:07:09 -0500

> mechanism and policy, and move the policy component down towards the 
user.

And make each CUA consume even more cycles rebuilding VFREEBUSY data and 
resending it.  Hmm, lets weigh that against having the CS do it 
automatically at a reduced cost in CUA load (thus better CUA performance) 
and network bandwidth in addition to the CS resources consumed to just 
deal with the added traffic. 

Im sure that every 'thin' client author is very anxious to make sure they 
also design their CUA so that it can _properly_ update the VFREEBUSY info 
too...  Then again maybe they will forgoe that and thin client CUs will 
just have no busytime to return...

VFREEBUSY is not a policy issue unless you are talking about 
READBUSYTIMEINFO VCARs.  VFREEBUSY data is intended to be:

   Purpose: Provide a grouping of component properties that describe
   either a request for free/busy time, describe a response to a request
   for free/busy time or describe a published set of busy time.

The jist of my first posting is that in CAP it is unclear just how 
busytime is looked up in real time.  In particular I find that CAP does 
not "specifies how to search for available busy time information" as 
promised in the 1st paragraph of Section 1.  Or at least it does not do it 
in a clear and unambiguious manner that I can understand.

In addition if you think there is a compelling need to have some 
TRANSparent property value that means "This entry is NOT to be represented 
in any VFREEBUSY property." then you'd better suggest some prose for it 
and some good motivation.  I for one think that such a case is very 
outside the norms of the day to day work environments that our target 
users live in.  By the combination of VCARs and TRANS properties I think 
that "That that need to see my busytime can, those that do not get 
nothing" can be achieved, even for your seemingly rare case.

> However, this is an edge case, and the costs seem pretty high. 

I agree.

>                                                                 Consider 

> this: if VFREEBUSY is compiled by the CUA, is there only one per user? 

Per 2445 there can be multiple ways of storing VFREEBUSY data (one or 
multiple VFREEBUSYs with one or mulitple FREEBUSY properties).  The more 
vexing case is does the CUA have ALL the calendar data necessary to 
properly regenerate VFREEBUSY every time it makes an update to the TARGET 
calendar?  Maybe, maybe not.

Still all this assumes we have some clear and consistant manner for easily 
getting the busytime for a user or set of users and I have yet to see it 
specified in CAP.  Hence my starting this thread....

>                                            If there are multiples, then 
> fetch each VFREEBUSY that overlaps that period, and combinet hem.

Already a requirement of 2445, Section 4.6.4:

                      Multiple "VFREEBUSY" calendar components can be
   specified within an iCalendar object. This permits the grouping of
   Free/Busy information into logical collections, such as monthly
   groups of busy time information.

[Snip]

   Free/Busy information is represented with the "FREEBUSY" property.
   This property provides a terse representation of time periods. One or
   more "FREEBUSY" properties can be specified in the "VFREEBUSY"
   calendar component.

so its perfectly possible that a response may have 1 VFREEBUSY with 
multiple FREEBUSY properties OR it can have multiple VFREEBUSYs with 1 or 
more FREEBUSY properties in it.

In order to make life a little easier on the recipient of said data there 
we added this to the definition of the FREEBUSY property:

   "FREEBUSY" properties within the "VFREEBUSY" calendar component
   SHOULD be sorted in ascending order, based on start time and then end
   time, with the earliest periods first.

so the CUA may be able to assume that once it finds a FREEBUSY in a 
VFREEBUSY that is after its interest date it can stop parsing the rest of 
the FREEBUSYs and go on to the next VFREEBUSY.  (It may also want to just 
keep parsing but thats an implimentation detail really).

>                                                                     If 

Whoa Hoss!  You may want to refresh yourself on busytime searchign in 
2445.  From Section 4.6.4 again:

   When used to request free/busy time information, the "ATTENDEE"
   property specifies the calendar users whose free/busy time is being
   requested; the "ORGANIZER" property specifies the calendar user who
   is requesting the free/busy time; the "DTSTART" and "DTEND"
   properties specify the window of time for which the free/busy time is
   being requested;

so the CUA can selectively bound the search range to be "Today @ 9AM thru 
Today @ 4:30PM" and it is expected that the response would only contain 
data for that range of time. 

As such the CUA wont have to sort thru all the VFREEBUSY data for my 
entire calendar starting back in 1996 thru 2045 (dont ask!); it should 
only be getting the data for the specified DTSTART/DTEND/DURATION range.

> period of interest, and get just the data it needs.

True.  If the CS actually stored the data in an index of some kind (cough, 
SQL table?, cough) then it may even be faster than if the data were 
generated dynamically.  It kinda depends on how tricky we allow busytime 
querying to become.  For example: just a simple date/time bounded range or 
do we allow querying based on entry criteria too!?  I for one say 
date/time bounding ONLY...

I still have more than a little concern that any CUA could just go muck in 
the VFREEBUSY data and make it totally unpresentative of the actual 
calendars status.  I also find that other concepts like moving VFREEBUSY 
data around somewhat useless at best and erroneous at worse. 

Still my first concern is still just how a CUA is supposed to query for 
busytime in CAP.  Doug has suggested that its just like in iTIP where the 
METHOD:REQUEST is sent out and then at some point later a METHOD:REPLY 
returns.  However this really describes a store and forward model of 
processing what is essentialy a realtime action. 

The response to the CREATE of the METHOD:REQUEST is "Ok, I created your 
VFREEBUSY REQUEST" and then the CUA has to poll some UNDETERMINED location 
presumably using the SEARCH command for some VFREEBUSY REPLY.  However 
just where this SEARCH would look is unspecified.  I also think that 
treating a busytime request like a mail message essentialy is the wrong 
approach to take. 

Then again I could just be misreading Dougs responses...  Am I alone or 
does anyone else share my confusion?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 01 Apr 2003 13:00:03 -0700

[email-masked] wrote:
> Umm, why should I (a CUA) be able to do that? 

Because this WG squashed it.

 >  Having VFREEBUSY info

No. It means that CAP does not specify it. It does not mean that
it can not be specified.

-- 

  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: John Stracke <[email-masked]>
Date: Tue, 01 Apr 2003 15:17:28 -0500

[email-masked] wrote:

> And make each CUA consume even more cycles rebuilding VFREEBUSY data 
> and resending it.  Hmm, lets weigh that against having the CS do it 
> automatically at a reduced cost in CUA load (thus better CUA 
> performance) and network bandwidth in addition to the CS resources 
> consumed to just deal with the added traffic. 

Note that this isn't necessarily conclusive--techniques for serving up 
relatively static data are well-known (think Web servers); it's usually 
cheaper than server-side processing.

> Im sure that every 'thin' client author is very anxious to make sure 
> they also design their CUA so that it can _properly_ update the 
> VFREEBUSY info too...  Then again maybe they will forgoe that and thin 
> client CUs will just have no busytime to return...

Note that most people would probably say that someone using a thin 
client probably has a fat client on their desktop.  Not a good answer, 
though; many people don't leave their desktops running all the time, so, 
if you accept an invitation with the thin client, your VFREEBUSY won't 
get updated until you next fire up your fat client.

> entire calendar starting back in 1996 thru 2045 (dont ask!);

You pre-expand repeating events, and cut them off after 50 years?

> it should only be getting the data for the specified 
> DTSTART/DTEND/DURATION range. 

This section was predicated on "if there is only one".  It sounds like 
the current plan is that the CS treats VFREEBUSY components as opaque, 
and just stores/delivers them for CUAs; in that case, the CS has to 
return the entirety of every VFREEBUSY that overlaps the requested 
range.  If there's only one per CU, that means every VFREEBUSY request 
will return all the data.

And the question arises: if there is more than one, how does it get 
updated properly? Suppose I have two CUAs; implementation A stores a 
separate VFREEBUSY for each week (starting on Sunday), and 
implementation B stores one for each month.  My calendar now has 
duplicate VFREEBUSYs for the same periods, and we have the opportunity 
for them to get out of sync.  For example, if A creates an event on 12 
April 2003, and updates its VFREEBUSY, but B doesn't update its 
VFREEBUSY for all of April, then any request for a VFREEBUSY for 12 
April will get two answers, one from the weekly component and one from 
the monthly.  Which one is the requester supposed to believe?

If, on the other hand, a CS is supposed to maintain freebusy data as 
data, and construct a VFREEBUSY from that data on request, then it's 
doing almost as much work as constructing a VFREEBUSY on request based 
on VEVENT data.

---

From: [email-masked]
Date: Wed, 2 Apr 2003 09:57:41 -0500

> No. It means that CAP does not specify it. It does not mean that

Perhaps we are talking about different things.  Im saying that if a CUA 
can craft any arbitrary VFREEBUSY data then it is very unlikely that the 
VFREEBUSY data I get from your calendar actually represents your busytime 
as VFREEBUSY data was designed and intended to do.

That is, I can have just 1 entry on my calendar for 11AM-12PM EST Today 
but the VFREEBUSY data on my calendar says Im 
FREEBUSY:20030402T060000Z/20030402T063000Z.  This makes busytime useless 
for trying to schedule with me.

CAP 1.0 currently allows (in theory) the ability for a CUA to CREATE or 
modify ANY component type.  This means that A) there is an implict burden 
on CUAs to maintain VFREEBUSY data to be in sync w/the calendar contents 
or B) VFREEBUSY data is an unreliable/useless mechanism in CAP.

I dont think we disagree about the need, I think Im just hearing that "The 
ADs want this critter out now so we cannot address it in CAP 1.0".  Can I 
start stuffing the ballot box w/lurker votes to get the required 20??... 
:^b

BTW: I dont think I saw an answer as to where my CUA would/should poll in 
order to get the iTIP VFREEBUSY REPLY.  Would that be a magically created 
UNPROCESSED document in _my_ calendar that I would have to SEARCH for?

Bruce

---

From: [email-masked]
Date: Wed, 2 Apr 2003 10:25:08 -0500

> cheaper than server-side processing.

I think you miss the scenario.  Short of maintaining a single VFREEBUSY 
with a single FREEBUSY property for _every_ calendar entry, there is NO 
quick or simple way for a CUA to find and update the VFREEBUSY that 
represents the amalgamation of multiple entries.  Even in the simplest 
case if you have 2 entries that overlap the CUA has to be sure to SEARCH 
for and update the correct VFREEBUSY.  (Remember that the UID in the 
VFREEBUSY is NOT the UID of the entry represented by any FREEBUSY property 
so its NOT a linkage mechanism!)

Since calendars change and can change frequently its not an issue of 
serving up a staticly generate response since a busytime request is a 
bounded response ("Give me Johns busytime between DTSTART and DTEND" where 
I can provide ANY values for DTSTART and DTEND I want.  They are NOT going 
to always match any statically generated VFREEBUSY data, esp. in the 
amalgamated case.

Since there are going to be 'thin' and 'thick' CUAs built and not every 
one will have all the ability to properly regenerate VFREEBUSY that 
accuratly reflect the calendar status I strongly think the onus for 
dealing with busytime belong on the CS and nowhere else.

In any case I think we are in violent agreement here (at least were were 
earlier).

> You pre-expand repeating events, and cut them off after 50 years?

You asked... :^) 

I didnt plan for stuff after the 50th wedding anniversary; thats going to 
be hard to top and Ill leave that to my twins to do...

>                                                        It sounds like 

Ugh!  What a waste and a kludge! 

In 2445 we clearly said that the requestor could bound the interval of 
interest and by just sending back a single "Heres my entire busytime" blob 
is an abuse of the system.  The original expectation was that the response 
would ONLY contain data relevant to that interval, not data for any 
arbitrary interval.

> doing almost as much work as constructing a VFREEBUSY on request based 

As expected, we are in violent agreement (although according to Doug this 
is an old issue and one the WG rejected but Im not so sure of that...) Now 
we just need 18 more folks to chime in and we can fix it before Last 
Call...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 08:59:00 -0700

[email-masked] wrote:
> VFREEBUSY data I get from your calendar actually represents your 
> busytime as VFREEBUSY data was designed and intended to do.

I think that it is less likely that we in this WG can draft a document
that will reflect what every CU and vertical application will want
in the VFREEBUSY data presented. Adding a BOT that gets it done will
allow the vendors to select what is or is not included without
having to specify at this time the procedure to create the VFREEBUSY object.

> for trying to schedule with me.

For some resource calendars that may be valid. Only the CUA/CU and
perhaps the CS knows. Maybe the resources for that time slot
are not filled up.

> modify ANY component type.  This means that A) there is an implict 
> burden on CUAs to maintain VFREEBUSY data to be in sync w/the calendar 
> contents or B) VFREEBUSY data is an unreliable/useless mechanism in CAP.

(A) is not completely true. It is your assertion that the VFREEBUSY time
must be 'in sync'. I could have different constraints such as blocking
out 9PM-6AM in the VFREEBUSY and never allowing any component to book
at those times. My VFREEBUSY time and the objects in my calendar
would then never be in sync. I could insert data in my VFREEBUSY time
for a 1 week vacation and not (see previous e-mail) have X number
of OPAQUE entries in my calendar for the 1 week vacation.

(B) is your opinion. I think it is just as likely that
a CUA could be busted in several ways (B) being only one of them.

> I dont think we disagree about the need, I think Im just hearing that 
> "The ADs want this critter out now so we cannot address it in CAP 1.0". 
>  Can I start stuffing the ballot box w/lurker votes to get the required 
> 20??... :^b

We do disagree. I agree that something must create the VFREEBUSY time
and I do not think that this WG can determine the how the data in
VFREEBUSY objects are created. And I think we disagree in our thinking
that the VFREEBUSY time and components in the calendar must be 'in sync'.
The VFREEBUSY time must be in sync with what the CU wants, not all
objects in the calendar.

I am saying that this is a topic in itself and does not need to be
in CAP.

> BTW: I dont think I saw an answer as to where my CUA would/should poll 
> in order to get the iTIP VFREEBUSY REPLY.  Would that be a magically 
> created UNPROCESSED document in _my_ calendar that I would have to 
> SEARCH for?

We also squashed notifications (yet another draft I have written
waiting for CAP). That will allow you to not have to POLL for
anything - including VFREEBUYSY.

--

---

From: [email-masked]
Date: Wed, 2 Apr 2003 15:58:03 -0500

Doug fired back on 04/02/2003 10:59:00 AM:
> in the VFREEBUSY data presented. 

Im not interested in new drafts now.  Im interested to see how something 
that is currently claimed to be available in CAP but I can find no prose 
for.

When we created the CS for CAP we have an added responsiblity to factor in 
stuff like access rights, busytime handling, etc.  We did the former.  I 
think we've overlooked the latter.

In iTIP we left generating the VFREEBUSY REPLY up to the ATTENDEEs using 
whatever mechanism they had tied into their MUA.  However in a 'realtime' 
environment that CAP is targeted at we cannot just play osterich...

> perhaps the CS knows. Maybe the resources for that time slot

Huh!?!?!  Exactly when would a potential user of a resource want to know 
the ABSOLUTE WRONG busytime information about that resource?!

Hmm, let me see...  Im sure LOTs of folks would love to book hotel rooms, 
rental cars, doctors visits, etc at times when the room, car, doctor are 
NOT available!  Happens ever day now that I think of it.  Sorry I asked...

The CS knows for sure the entire contents of any given calendar within the 
CS and as such it has the best picture of the busytime represented by the 
contents therein.  The CU/CUA may have a partial view of things but they 
are not guaranteed to be as current as the CS's view of things.  For 
example:  You may know your schedule for today but if your AA schedules a 
1-on-1 w/your boss (and has Direct Book ablities) then the CS knows you 
are now busy but you _do not_.  As such you would fail to update the 
VFREEBUSY data properly.  Then again your could poll for new entries that 
someone _may_ have direct booked and then update the VFREEBUSY info 
(belatedly).  Yeah, thats scales well...

> must be 'in sync'. 

If busytime is NOT 'in sync' (within some reasonable window) then it is 
useless to anyone that would use it.  Inaccurate busytime information is 
worse than NO busytime information because it leads to nothing but 
frustration and extra workflow ("Gee your busytime said you were free in 
the AM but not in the PM but you say you only have a 9AM meeting.  If I 
had known I could have invited Pat as well.  Now Ill have to try again.").

>                      I could have different constraints such as blocking
> at those times. 

Booking is totally separate from busytime. 

I can always overbook (assuming the 'conflict settings' of the conflicts 
allow it) no matter what the busytime settings say ("I now I already have 
a meeting at 9AM, save this one anyway!")!  Busytime merely informs the 
viewer of entries in the calendar; it has 0, NONE, ZIP effect on any kind 
of booking policy.  Thats a totally separate issue. 

>                 My VFREEBUSY time and the objects in my calendar

And I could still try to book a meeting with you then as the CS has 
NOTHING in it for that time that is marked as TRANSP:OPAQUE-NOCONFLICT. So 
what was achieved??

The much more normal convention is to put some entry on your calendar that 
reflects the fact your are "Busy - Unavailable".  That is then reflected 
in your VFREEBUSY data.  That way someone who have access to see your 
calendar will also see that you have some "Vacation!!" entry there and not 
assume that they can book you for something.  ("Hmm, Looking at Dougs 
calendar I see he has all of Tuesday free but the busytime check says hes 
unavailable.  I wonder why I cant see something then!?") 

I have plenty of first hand experience dealing with disjoins between 
calendars and busytime results so I am very confident in this being the 
norm rather than an exception.

> (B) is your opinion. 

Yes it is.  It also happens to be easily demonstrable that if you provide 
incorrect or misleading busytime information you GREATLY increase user 
frustration and dissatisfaction with the feature to the point that they 
wont use it at all!

There is NO prose anywhere in CAP about how/when VFREEBUSY information is 
maintained and I view that a big problem in a protocol that is supposed to 
be a C&S protocol.  By letting anyone generate VFREEBUSY data that has NO 
relation to the associated TARGETs contents you end up with useless or 
missing data!  That just makes the feature unreliable and useless itself.

>                     I agree that something must create the VFREEBUSY 
time
> VFREEBUSY objects are created. 

I think we _could_ but think that because time is short some folks do not 
want to try.  If noone else wants this then remove the line "It further 
specifies how to search for available busy time information" from Seciton 
1 and ship it.  In any case I see no prose ANYWHERE in CAP 1.0 that "
specifies how to search for available busy time information" and thats the 
point Ill keep coming back to until it sinks in.  CAP claims to do 
something that it has NOT.

>                                 And I think we disagree in our thinking

If you could give me a real case where having VFREEBUSY and calendar 
content OUT OF SYNC is good then I would consider it.  However I 
_constantly_ hear that users want the data to _always_ be in sync. 

> The VFREEBUSY time must be in sync with what the CU wants, not all

Reality check time.  Putting 'phantom' data into the VFREEBUSY does not 
achieve anything worthwhile.  It does NOT preclude someone from booking 
then because we have NEVER said that a CUA MUST use VFREEBUSY information 
as a filter for CREATEing entries.  As such, even though your VFREEBUSY 
says you are BUSY for next week, that would not prevent me from 
'overbooking' a meeting with you.  If you really wanted to block next week 
off then more than likely create an entry that lasted all week so that 
noone could overbook you.

Back to basics time: the VFREEBUSY represents the busytime of the TARGET 
calendars.  If a CU wants to be unavailable then putting the proper entry 
on the calendar is the proper way to go.  Not having calendar entries in 
the VFREEBUSY that are in the calendar achieves what?  Nothing but 
frustration and anger.  After all, if you cannot rely on the VFREEBUSY 
data, why bother checking it??

Its the job of the CUA and CS to manifest the CUs wishes in the proper 
way.  Doing so in any other manner is not a smart idea...

> I am saying that this is a topic in itself and does not need to be

Thats your opinion.

> anything - including VFREEBUYSY.

Still no answer... Check!

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 14:49:14 -0700

> that is currently claimed to be available in CAP but I can find no prose 

I do not follow how your point has anything to do with the paragraph
that you cited.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 15:12:17 -0700

> the ABSOLUTE WRONG busytime information about that resource?!

Never - and it is a good thing that we agree that a CUA/CS should
never report ABSOLUTE WRONG busytime information.

However for resource calendars mapping components to busytime
is not always 1:1. There can be BUSY time with no entries in any
calendar. And for resource calendars you can have entries that
do not create busy time. Think of a pool of conference rooms
with similar properties. The busy time is not filled in until
all of the conference rooms are booked. There are times when
a there is not a 1:1 mapping between booked components and
busy time.

The rules of how to compute busy time vary depending on the
application and user preferences (sleep time).

> useless to anyone that would use it.

We agree - it is reasonable for them to be out of sync :-)

> Inaccurate busytime information is 

'Inaccurate' is only relative to the correctness of busy time for the
owning CU. If they compute more busy time that your application then
it is not inaccurate - you simply do not know how they computed it.

The same is true for resource calendars. Just because 1 of the pool
of conference rooms is booked does not mean that no one can book
another of the rooms at the same time. Refer to the WG discussions
pre-iCal about the LA time frame. It was the last one where I
saw Pete O'Leary (before he sold his company?)

> Booking is totally separate from busytime.  

We agree. They are not going to always be in sync.

> allow it) no matter what the busytime settings say ("I now I already 
> have a meeting at 9AM, save this one anyway!")!  Busytime merely informs 
> the viewer of entries in the calendar; it has 0, NONE, ZIP effect on any 
> kind of booking policy.  Thats a totally separate issue.  

Which is exactly my point. How that time is computed is going to have
to be flexible.

> NOTHING in it for that time that is marked as TRANSP:OPAQUE-NOCONFLICT. 
>  So what was achieved??

If you or your CUA choose to ignore that that week is shown as
busy time, then when I get back from vacation I would decline your
METHOD:REQUEST.

> The much more normal convention is to put some entry on your calendar 
> that reflects the fact your are "Busy - Unavailable".  That is then 
> reflected in your VFREEBUSY data.  That way someone who have access to 
> see your calendar will also see that you have some "Vacation!!" entry 
> there and not assume that they can book you for something.  ("Hmm, 
> Looking at Dougs calendar I see he has all of Tuesday free but the 
> busytime check says hes unavailable.  I wonder why I cant see something 
> then!?")  

Perhaps:
   (1) You do not have access to the other entries.
   (2) I did not want to make X number of entries in my calendar to
       each marked as vacation in order to work around my regular
       entries that are OPAQUE that keep me from making 1 single
       vacation entry.
   (3) I did not want to delete my regular OPAQUE entries for that
       week, so I just told my CUA to deposit a VFREEBUSY info
       my calendar showing that I am busy that week.

> norm rather than an exception.

I think we agree - they do not have to be in sync.

>  > (B) is your opinion.
> 
> Yes it is.  It also happens to be easily demonstrable that if you 
> provide incorrect or misleading busytime information you GREATLY 
> increase user frustration and dissatisfaction with the feature to the 
> point that they wont use it at all!

It not incorrect busy time. It just not computed the same way
as you compute yours.

>  >                     I agree that something must create the VFREEBUSY time
> I think we _could_ but think that because time is short some folks do 
> not want to try.  If noone else wants this then remove the line "It 
> further specifies how to search for available busy time information" 
> from Seciton 1 and ship it.  In any case I see no prose ANYWHERE in CAP 
> 1.0 that "specifies how to search for available busy time information" 
> and thats the point Ill keep coming back to until it sinks in.  CAP 
> claims to do something that it has NOT.

SELECT * FROM VFREEBUSY where DTSTART > something AND DTEND < something-eles.

> _constantly_ hear that users want the data to _always_ be in sync.

You have given examples yourself in your email that it is valid
to not always be in sync. (The one I am replying to with this
message).

--

---

From: [email-masked]
Date: Thu, 3 Apr 2003 10:18:56 -0500

> I do not follow how your point has anything to do with the paragraph

You said that the WG "can draft a document" and thats NOT CAP so it would 
have to be a new draft.  I dont want to see a new draft, I want to see 
this working/fixed in CAP.

Bruce

---

From: [email-masked]
Date: Thu, 3 Apr 2003 16:23:07 -0500

<WARNING>
This has gotten somewhat long and a bit off the base topic.  Ill try to 
conclude this digression and get back to the base topic!
</WARNING>

> never report ABSOLUTE WRONG busytime information.

Goodness that we do agree (and I suspect we agree on other points too). 

However I strongly think that allowing/expecting the CUAs to do VFREEBUSY 
creation/maintenance (as appears to be the implicit expectations now) is 
VERY BAD and should be prevented.  I expect that you would also agree to 
this in concept but maybe not in how its achieved (or maybe not 100% 
entirely).

> calendar. 

Sounds like you are taking about profilable 'work hours' or 'available 
hours' so that folks know "When is Doug available for meetings?" or "When 
is Room 1 'accessible'?".

More nifty features we've had in Notes for years now.  While I like that 
concept I do not expect it to be in CAP 1.0.  For CAP 1.0 I think that 
having VFREEBUSYs reflect just the calendar contents is a good first step. 
 Adding stuff like this post-CAP 1.0 is the way to go I think....

>            And for resource calendars you can have entries that
> with similar properties. 

"Pooling" is like "group calendars" and NOT something we are building in 
CAP 1.0.   Not a worthwhile example to use now...

>                           The busy time is not filled in until
> all of the conference rooms are booked. 

Ahh, I see now.  Rolling up the busytime of several rooms into 1 'master' 
busytime entry is something that I agree that was quashed in 1999 by the 
WG.  In your view, when building a busytime roll-up system the busytime 
may not reflect just the contents of a calendar because it may be rolled 
up from others instead (or in addition?).  In any case, this is NOT 
something Im concerned with and I think is a confusing factor in this 
discussion.

Each separate room is busy if its booked and as such MUST be reflected in 
a busytime lookup for that room if checked directly.

> application and user preferences (sleep time).

Not really.

If there is an entry on the calendar then its should be immediately 
reflected in the busytime data for that calendar.  The only reason for it 
to NOT appear that I can think of is that there may be a slight lag in 
creating the entry and it actually showing up in busytime (ie: a couple 
seconds delay as its processed and flushed to disk).

User preferences on when to compute busytime have NO input into the matter 
in a real time environment.  What user really wants to "Update my busytime 
1 hour after I add any new entries."?

I get calls about "This morning I put an appointment on my calendar for 
3PM on Tuesday but when Sue checks my busytime it appears as if Im free. 
Why?".  I NEVER get calls "I put 2 appointments on my calendar this just 
now but I dont want them to show up in busytime until tonight.  How do I 
do this?".

> We agree - it is reasonable for them to be out of sync :-)

More goodness...

> it is not inaccurate - you simply do not know how they computed it.

I think I now how to do busytime; Im the guy responsible for it in Lotus 
Notes and have been for since nearly the initial release of it Notes.

Correctness is relative to the calendars contents, not the CUs opinion of 
how busytime should look.  If CUs want to achieve something then the CUA 
simply constructs the proper calendar entry and it gets reflected in 
busytime.  To 'undo' the effect they change or remove the entry.  Trying 
to do manual maintenance of busytime of 'non-calendar entires' on an 
ad-hoc basis and NOT basing it on calendar data is too error prone to be 
of any good. 

> of conference rooms [Snip]

Bringning up pooling or calendar / busytime roll-up is a digression from 
the base issue I started with and has already been quashed.  Lets not try 
to use it now in resolving my questions please.

> We agree. They are not going to always be in sync.

My point was that the ability to book an entry is a completely separate 
issue from "Is Doug free @ 7PM EST for a meeting?".  I may see you are 
busy from 6PM thru 9AM but I may still be able to CREATE a meeting 
invitation for that time.  Busytime has no policy impact on entry 
creation.  That is NOT to say that once booked for 7PM - 8PM EST your 
busytime is NOT reflective of the new entry!

For CAP 1.0 Im NOT trying to build the most robust busytime system with 
tons of cool features.  Its too close to ship date.  Im trying to make 
sure that I can do the most elementary busytime lookups in CAP and be 
somewhat secure in the results returned are accurate of the calendars 
current status.

> Which is exactly my point. How that time is computed is going to have

Not sure I follow here.  You agree that busytime is informative and has no 
effect on the booking policy of the user.  I assume that you also agree 
then that once a new entry is booked that it MUST be reflected in a 
subsequent busytime lookup.  I for one think that the CS is the place to 
do that maintenance, NOT the CUA.  I also think that this needs to be in 
CAP 1.0 for busytime to be even remotely useable 'out of the gates'. Would 
you agree?

> busy time, then when I get back from vacation I would decline your

Whats there for me or my CUA to ignore?  There has been NO change proposed 
to fbtypeparam to include "no conflict" as a 'type' of FREEBUSY.  In 
addition new "no conflict" types are for CAPs use so that when someone 
trys to overbook they are prevented. 

It sounds as if you are implicitly expecting that all attempts at workflow 
are somewhat controlled by busytime results ("You cannot meet with Pat @ 
3PM, she has an entry that does not allow you to overbook!"). I think this 
is the wrong approach to take in using busytime.  Busytime is informative 
only.  It SHOULD be accurate but it SHOULD NOT prevent you from inviting 
Pat to that meeting.  She may see your REQUEST, decide to try and call in 
and allow herself to be overbooked (its HER choice).  She may see it and 
COUNTER you to a better time.  The "no conflict" control should only be 
enforced by the CS and the calendar CU has the final arbitration in 
allowing stuff like conflicts, etc.  Busytime does NOT.

In any case we have greatly digressed from my original question and Im 
still looking for the answer: 

How do I get busytime information from other users via CAP?  (The followon 
question seems to be Who is responsible for keeping the busytime 
information updated and when?) 

>    (1) You do not have access to the other entries.

I dont need access to the other entries for the CS to see that they are 
"no conflict" and thus prevent my booking a conflict.  Only the CS needs 
that access so it can reject the CREATE.

>        entries that are OPAQUE that keep me from making 1 single

You as the CUA have the final say so in allowing conflicts to your own 
calendar.  As such you should be able to create any kinds of entries you 
like whenver you want.  Any other design is fundamentally flawed.

>        my calendar showing that I am busy that week.

See #2...

> I think we agree - they do not have to be in sync.

Still more goodness...

> It not incorrect busy time. It just not computed the same way

It boils down to who maintains the busytime then. 

I contend that only the CS can consitantly and accurately represent the 
busytime of a calendar within it and that a CUA may be able to but not in 
consistant and accurate manner without becoming overly burdensome.  If the 
design of CAP is such that its indeterminate who is to maintain the 
busytime info then I think its a fundamental flaw in CAP.

> SELECT * FROM VFREEBUSY where DTSTART > something AND DTEND < 
something-eles.

Hmm, 2 problems with this:

1: Thats different from your original answer of "its the same as in iTIP". 
 Under that mode the CUA would CREATE a VFREEBUSY REQUEST and then have to 
poll _someplace_ TBD for the VFREEBUSY REPLY.  Im not sure which is how 
you think CAP specifies it...

2: VFREEBUSYs use DTSTART / DTEND to delimit the bounds for the contained 
busytime information.  Unless you build some better selection criteria OR 
you coerce the DTSTART / DTEND pairs to be similar in duration your SEARCH 
may not find VFREEBUSYs that it should. 

For example, if the VFREEBUSY info within the CS is stored using day 
increments (ie: DTSTART:20030402 / DTEND:20030402  for yesterday, 
DTSTART:20030403 / DTEND:20030403 for today, etc) but your SEARCH criteria 
is simply for "When is Doug free this AM" (ie: DTSTART:20030403T120000Z / 
DTEND:20030403T170000Z) then NO VFREEBUSYs would match the SEARCHs' WHERE 
clause and NOTHING would get returned because the DTEND of the SELECT is _
before_ the DTEND of the VFREBUSY for today! 

The ONLY way to use the kind of SEARCH you suggest is to search for a 
matching time slice and then ignore what I dont need.  For example, I may 
want to know "When is Doug free this AM" but my SEARCH would have know to 
use "WHERE DTSTART >= 20030403 AND DTEND <= 20030404" and then just ignore 
all the extra data it gets back.  This of course means that the CUA would 
have to know the granularity of the VFREEBUSY data its searching AND that 
the potential waste of bandwidth with the extra data is a necessary 
evil...

> to not always be in sync. (The one I am replying to with this

Having a small window where they are not in sync is acceptable (ie: the 
time it takes to process it and save the 'cache' info to disk).  Thats the 
ONLY time it wont be in sync that Ive ever mentioned as not evil! 

> for trying to schedule with me.

For some resource calendars that may be valid. 

but I have yet to hear any validation of this claim. 

When is having data that does NOT represent the calendars contents or even 
blatently misrepesents it a 'valid' case?!? 

Busytime should always accurately reflect the status of the calendar based 
on its contents! 

And still I dont see where in CAP I overlooked where it "specifies how to 
search for available busy time information"...  Maybe I need some glasses.

Waiter!!

Bruce