Subject: Re: CAP & busytime?

From: [email-masked]
Date: Tue, 1 Apr 2003 11:27:19 -0500

Doug wrote on 03/31/2003 06:12:54 PM:
> > For busytime, iTIP uses the VFREEBUSY component with METHOD:REQUEST or 

> > METHOD:REPLY for requesting and responding, respectively.  In CAP, I 
> > guess that would crudely map to a CREATE command with particular 
TARGETs 
> > but there is NOTHING to lead me to belive that the CS must do any 
actual 
> > processing beyond the actual request creation. 
> 
> In fact we squashed the CS from doing any work for the CUA.
> You need to have your CUA or a CUA-BOT do it for you.

I dont recall that decision and I certainly think making VFREEBUSY data 
totally disjoint from the contents of the associated calendar is a BAD 
idea.  It makes busytime useless if we have no clear and consistant design 
for doing busytime lookups and now busytime data is maintained. 

How can any CU reasonably expect to do any kind of scheduling with other 
users if busytime information is NOT guaranteed to be in sync w/the 
calendar contents (or reasonably close to it assuming some lag in 
updating)?

We already mandate that a CS MUST provide support for a READBUSYTIMEINFO 
VCAR so its reasonable to expect that the CS would maintain that busytime 
info rather than relying on CUAs to do this maintenance or some totally 
unspecified "Bot" mechanism.   After all, since VFREEBUSY have NO linkage 
information to the actual entries in a calendar (go recheck 2445 if you 
dont believe me, Section 4.6.4 Free/Busy Component) there is very little 
chance that a CUA can properly maintain the 'digested' info in a 
VFREEBUSY.    And making the prescious 'thin' clients 

The only reasonble source for keeping the VFREEBUSY accurate is to have it 
done by the CS as changes are made to the calendar.  _Assuming_ that an 
unspecified "Bot" mechanism  is the way that it should/would/MAY be done 
is NOT sufficient here if we want that key functionality in CAP.  CAP 1.0 
needs to provide that basic functionality in it or we severly risk loosing 
user adoption.

> > Actually it is not.  The only ANBF in SEARCH is:
> 
> Read more text...:
> 
>       comp-name  = "VEVENT"  / "VTODO"     / "VJOURNAL" / "VFREEBUSY"
>                  / "VALARM"  / "DAYLIGHT"  / "STANDARD" / "VAGENDA"
>                  / "VCAR"    / "VCALSTORE" / "VQUERY"   / "VTIMEZONE"
>                  / x-comp    / iana-comp
> 
> 
> And comp-name is used in:
> 
>    cal-query  = "SELECT"   SP   cap-val  SP
>                 "FROM"     SP   comp-name SP
>                 "WHERE"    SP   cap-expr
> 

Umm, sorry but that ABNF is NOT under SEARCH.   That ABNF is part of 
Section 6.1.1. CAL-QUERY Value Type which is concerned with "Registration 
of text/calendar MIME value type CAL-QUERY"

Perhaps you meant to say "SELECT" instead of SEARCH..??

A cal-query data type is used for the QUERY (Section 8.26), RESTRICTION 
(Section 8.33) and SCOPE (Section 8.34) properties.  The latter 2 are 
related to VCARs.  The former appears ONLY referenced in the ABNF for the 
VQUERY component (Section 9.6).  If you recheck your draft you will find 
that the ONLY references to a VQUERY component usage is in the CREATE 
command:

 create-comp = agendac / carc / queryc
               / timezonec / freebusyc
               / eventc / todoc / journalc
               / iana-comp / x-component

NOWHERE else in the ABNF do I find any reference to the queryc.   As such 
it is illegal for me to use a VQUERY in any other command OTHER than a 
CREATE one (a comment I made many moon ago but must have been forgotten). 

Then again, the create-object in the ABNF is referenced NOWHERE in the 
draft either so something is either very wrong w/the find text feature of 
MSIE or there is some really bad ABNF here...  However this is a topic for 
a new thread I think...

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, 01 Apr 2003 12:34:53 -0700

[email-masked] wrote:
> idea. 

It was under the 'roll-up' discussion. Only you and I thought it
was a good idea. The WG smashed it.

-- 

  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: Doug Royer <[email-masked]>
Date: Tue, 01 Apr 2003 12:58:06 -0700

[email-masked] wrote:

> The only reasonble source for keeping the VFREEBUSY accurate is to have 
> it done by the CS as changes are made to the calendar.  _Assuming_ that 
> an unspecified "Bot" mechanism  is the way that it should/would/MAY be 
> done is NOT sufficient here if we want that key functionality in CAP. 
>  CAP 1.0 needs to provide that basic functionality in it or we severly 
> risk loosing user adoption.

Need told me and Pat repeated that we can not add features to CAP
unless 20 people on this list insist tht it must be done. We
are shipping CAP soon ! :-)

I am in the processing of updating my CUA-BOT draft (never sent)
as an add-on to CAP.

--

---

From: Dan Winship <[email-masked]>
Date: 01 Apr 2003 16:58:18 -0500

On Tue, 2003-04-01 at 14:58, Doug Royer wrote:
> unless 20 people on this list insist tht it must be done.

Well, I agree with Bruce, so there's 2...

-- Dan

---

From: John Stracke <[email-masked]>
Date: Tue, 01 Apr 2003 17:11:39 -0500

>Well, I agree with Bruce, so there's 2...
3.

-- 
/============================================================\
|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: "Paul B. Hill" <[email-masked]>
Date: Tue, 1 Apr 2003 18:04:02 -0500

OK, we're up to 4. Keep those "votes" coming :)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Dan Winship
Sent: Tuesday, April 01, 2003 4:58 PM
To: [email-masked]
Subject: Re: CAP & busytime? - not CAP reqirement - CUA-BOT

-- Dan

---

From: [email-masked]
Date: Wed, 2 Apr 2003 09:21:17 -0500

> was a good idea. The WG smashed it.

Hmm, Im unable to find 'roll-up' in the busytime context in my archives. I 
do see that we had some discussions (and agreement) on NOT doing calendar 
_content_ roll-up but I see nothing in the context of automatic busytime 
'roll-up'.

The phrase 'roll-up' appears in 3 threads (excluding this current thread):

1: "(long) problems with CAP not having "users" and hierarchical calendars
" started 04/09/99 04:46:03 PM AST by Paul Hill
2: "Rollup of calendar content" started 05/19/99 02:23:53 PM GMT by Frank 
Dawson
3: "Proposed removal of hierarchy from CAP" started pre-12/28/2001 
02:05:05 PM MST and discussed by Doug Royer, Steve Mansour and Shannon 
Clark

The first two threads discuss the issues inherent in calendar content 
rollup and were basically agreed on by all that for CAP 1.0 we do NOT have 
calendar content roll-up (or rollup).  This is still a good thing.  (Doug: 
Do you still have that separate roll-up draft on hold?)

The last thread was really discussing the issues around relationships and 
content rollup and is not related to any busytime discussions.

There was some discussion of the impact on content rollup when doing 
busytime queries in the 1st thread (and Doug only briefly mentioned it 1 
time in the 2nd thread) but the gist of the references were that content 
roll-up would make doing busytime searching inaccurate (ie: The actual 
VEVENT could be in a 'child calendar' and thus not findable when TARGETing 
a parent calendar for finding it) or unreliable (ie: "The FREEBUSY says Im 
busy from 1PM-1:30PM today but there is NOTHING on my calendar for that 
time.  What gives?").

I can find no "We shall not make dynamic/automatic busytime maintenance a 
CAP 1.0 feature" decision in the archives.  From what Ive heard so far 
from others is that having the CS do the lifting here rather than make all 
CUAs do it is the right thing to do, its just that Doug thinks this was 
already covered and considered Closed.  That sound accurate?

Bruce

---

From: [email-masked]
Date: Wed, 2 Apr 2003 09:45:29 -0500

> are shipping CAP soon ! :-)

Passing WG Last Call is what we all want but if it just goes to the next 
step and someone raises the issue of "Hey, this 'Scheduling' protocol has 
no way to get busytime information.  Why not?" then its gonna come back to 
us for fixing since I think that we all agree its not a minor quibble over 
textual phrasing.

Keeping feature creep out is very critical as we go that last mile to 
passing Last Call but this is NOT a "I want to be able request entries in 
the color Blue" kind of feature request; its a fairly basic usablity 
feature we havent clearly defined IMHO.

> I am in the processing of updating my CUA-BOT draft (never sent)

FWIW, adding 'Bots' to a CS is invisible to all but the CS Admins. 
CUs/CUAs only see the functionality thru commands, returned results or 
GET-CAPABILITY responses so they dont know/care if its a Bot, Perl script 
or highly polished C++ code.  Still, Id be interested in reading your 
proposal (even offline).

Bruce

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 10:15:37 -0500

[email-masked] wrote:

>  CUs/CUAs only see the functionality thru commands, returned results 
> or GET-CAPABILITY responses so they dont know/care if its a Bot,

In this case, people would care, because a bot could not update the 
freebusy information immediately (we don't have notifications of 
changes), so there would always be a lag between adding an event and 
seeing the updated VFREEBUSY.  And admins would resent the performance 
cost of having those bots polling all the time, so they would try to 
keep that poll interval long, which would make that lag worse.  
Performance would probably be better if the VFREEBUSY were being 
generated in the CS.

---

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

[email-masked] wrote:
> step and someone raises the issue of "Hey, this 'Scheduling' protocol 
> has no way to get busytime information.

You already know that the above is not true. The CUA can do a SEARCH
for VFREEBUSY  components. So I have no idea how to respond
to your conclusion based on your assertion.

--

---

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

[email-masked] wrote:

> GET-CAPABILITY responses so they dont know/care if its a Bot, Perl 
> script or highly polished C++ code.  Still, Id be interested in reading 
> your proposal (even offline).

Its effect is visible to the CU and CUA which is its purpose.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 09:07:03 -0700

> Performance would probably be better if the VFREEBUSY were being 

I for one would compile in my VFREEBUSY-BOT into my CS to avoid
the poll problem. How the contents of the VFREEBUSY time objects
are created is under dispute.
--

---

From: [email-masked]
Date: Wed, 2 Apr 2003 14:27:08 -0500

John replied on 04/02/2003 10:15:37 AM:
> seeing the updated VFREEBUSY. 

This is all a digression from the main thread so Ill just say 1 last thing 
on it. 

That all sounds like an issue w/how you built your 'Bots' then rather than 
an issue with CAP.  After all, if you built your 'Bot' mechanism so that 
they got to do things BEFORE the command completed then there is NO lag. 
If you built it so your 'Bot' mechanism so that its asynchronous from 
CS/CUA actions then yes you will have some lag (and the lag depends on 
your internal architecture, server load, etc).  However that lag should 
not be that bad unless you only run your 'Bot' every hour or so...

Now lets refocus on the original question/issue.  Check please...

Bruce

---

From: [email-masked]
Date: Wed, 2 Apr 2003 14:38:04 -0500

Doug answered on 04/02/2003 10:37:46 AM:
> You already know that the above is not true. 

Hate to burst your bubble but passing WG Last Call is not the only step in 
becomming an RFC.  We have to pass others and if comments received are 
considered significant enough to warrant reworking then the draft _IS_ 
sent back to the WG for fixing.

>                                               The CUA can do a SEARCH
> for VFREEBUSY  components. 

So your answer to my question is that to get busytime information the CUA 
simply sends a:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//someone's prodid
CMD:SEARCH
TARGET:BrucesCalendar
TARGET:DougsCalendar
BEGIN:VQUERY
QUERY:SELECT * FROM VFREEBUSY WHERE DTEND >= '20030402T080000Z' AND 
DTSTART <= '20030402T190000Z'
END:VQUERY
END:VCALENDAR

That sounds different than your first reponse which was "Its like in 
iTIP...".   Am I misunderstanding you now or is the above correct?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Apr 2003 13:27:26 -0700

[email-masked] wrote:
> Hate to burst your bubble but passing WG Last Call is not the only step 
> in becomming an RFC.  We have to pass others and if comments received 
> are considered significant enough to warrant reworking then the draft 
> _IS_ sent back to the WG for fixing.

True but not relevant to my point - Yes you can get an put
VFREEBUSY in CAP.

--

---

From: John Stracke <[email-masked]>
Date: Wed, 02 Apr 2003 15:08:07 -0500

[email-masked] wrote:

> This is all a digression from the main thread

No, it's not.  The assertion has been made that having a bot would let 
us get away with not having the CS generate VFREEBUSYs; my point is that 
that is not an adequate solution.

> That all sounds like an issue w/how you built your 'Bots' then rather 
> than an issue with CAP.  After all, if you built your 'Bot' mechanism 
> so that they got to do things BEFORE the command completed then there 
> is NO lag.

Uh...and how is that done? A bot generally means an application that 
runs as a client.  What you're talking about would require notifications 
in CAP.

If you're talking about some sort of out-of-band integration with the 
CS, then how is that different from having the CS build the VFREEBUSYs 
itself? From the CAP point of view, it's purely a matter of internal 
architecture.

> your internal architecture, server load, etc).  However that lag 
> should not be that bad unless you only run your 'Bot' every hour or so...

Once an hour is *expensive*.  Think about it: when sizing the server 
needed for N users, one makes assumptions on how often those users will 
consult their calendar.  A reasonable assumption is that an average user 
will not check their monthly view more than once per hour.  This 
freebusy bot is going to be at least as expensive as a monthly view, 
since it has to update *every* range in the user's calendar.  So, with 
bots polling once per hour per user (which isn't really often enough), 
you're talking about at least doubling the load on the CS.

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 3 Apr 2003 13:53:24 -0500

From: "Paul B. Hill" <[email-masked]>
   Date: Tue, 1 Apr 2003 18:04:02 -0500

At the recent IETF I was completely stunned that CAP was designed as
an access to an iCalendar store for clients to do their own iTIP
processing, and not as an access protocol to a calendaring server.

I believe it should synthesize freebusy components---so another vote
in favor.

I believe that we'll hit this same disconnect on "how do I invite
someone to a meeting". (Do I have to upload one component? Many
components?)

Larry

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Apr 2003 13:08:44 -0700

> someone to a meeting". (Do I have to upload one component? Many

You deposit a iTIP request in the target CUs mailbox. When
the target CU/CUA accesses their calendar, they reply.

--