Subject: RE: RECAP & Questions of CPL RECUR Issues.

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 May 2001 23:26:19 -0400

> -----Original Message-----
> From: Shannon J. Clark [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2001 7:09 PM
> To: [email-masked]
> Subject: RE: RECAP & Questions of CPL RECUR Issues.
> 
> 
> A few quick observations.
> 
> If CPL is proposing an algorithm that tests "whether the date-time
> intersected the rule" this implies that given a large set of 
> RRULES - ALL
> rules must be tested at ALL points in time... this seems 
> potentially very
> complex vs. evaluating out the RRULES and testing against a set that
> contains all occurrences for ALL objects (for the given 
> calendar) - which
> should be a very manageable test.
> 
> I.E. - are they really proposing that for every point in time 
> that their
> software needs to "do" something, it checks (and evaluates) 
> ALL RRULES on
> ALL objects in the calendar(s) present for the software and then do
> something based on those events?

The specifications don't mandate one way or the other. I suspect the current
implementations probably do evaluate the RRULES on all objects to find a
match against the current time, when an incoming call arrives. 

In typical CPL usage, a user will make use of some kind of tool to specify
some call features they would like to apply. The CPL specifying those
features is then constructed and uploaded to a server. The means by which it
is uploaded are outside the specification, and several possibilities exist.
Jonathan L. has written a draft that proposes using SIP REGISTER for
uploading the CPL:

http://search.ietf.org/internet-drafts/draft-lennox-sip-reg-payload-01.txt

at that time, the server validates the CPL and stores it. When a call
arrives for that user, the CPL is fetched and processed to determine how to
handle the call. It is possible that the CPL had a time-switch, which
determines call processing actions based on whether the current time of day
is within a recurrence.

You can read more about CPL usage scenarios in RFC2824.

Typically, a single server will store and manage a large number of CPL
scripts, one for each of the users it owns. 

> 
> In developing my company's software we are evaluating RRULES 
> when the enter
> our server to get to a set of occurrences - subsequently we 
> check against
> this set for occurrences that overlap the period of time that 
> we need to
> evaluate for. 

Interesting. So, for the CPL case, you would basically expand the
recurrences at CPL upload time, trim those in the past or far in the future,
and then store the CPL script with the subset of the recurrences?

Presumably this would require storage of the recurrences, so that we still
want to have bounds on that size.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 17 May 2001 11:23:40 -0500

Jonathan,

Thanks for the explanation about the CPL usage.

Some observations that this leads to about calendar usage in general and
RRULES specifically.

CPL has a model of use that supposed FEW  calendar objects in a calendar
(you cite one, I suspect in real usage it will be more than one but still a
small number). CPL is also interested in a POINT TIME question - i.e. which
CalObjects apply NOW (where "NOW" is the current time of the switch, perhaps
adjusted per the user's timezone settings).

My software, and I suspect many other company's software in the
calendaring/scheduling space have a model which assumes MANY CalObjects for
a given user (perhaps in one vCalendar, perhaps in a collection of
vCalendars) and are mostly dealing with TIME RANGES - i.e. what CalObjects
to return for "TODAY", "THIS WEEK", "NEXT MONTH" - this frequently is based
on a use of "NOW" also adjusted for the user's timezone settings, but from a
calendar server's perspective is rarely dealing with POINT TIME issues.

This leads to a number of algorithmic differences - which may also point to
some simplifications for CPL.

One - CPL may NOT need to deal with the full set of occurrences of each
CalObject - rather, CPL needs an algorithm that given the following
properties of the CalObject and "NOW" returns whether the given CalObject is
in effect "NOW": DTSTART, DTEND, DURATION, + all RRULE properties (including
exception rules). Processing can perhaps take advantage of various
optimizations made possible by these constraints.

Two - since CPL assumes FEW CalObjects it is probable that the calculation
time needed to check each CalObject at every usage occurrence (i.e. whenever
a call comes into the switch) is manageable - but does need to be very fast
so as not to delay the processing of the call. CPL will need to deal with
aging of events - otherwise after a while there will be more CalObjects that
occur only in the past than are potentially applicable to the present.

Three - CPL's model of usage appears to imply no need to worry about the
future OR the past - all CPL is concerned with is whether or not the
CalObject is active NOW (where "active" is defined by Start/end/duration
settings on the object) this differs from traditional calendar usage with is
concerned with the past, the future, and the present period (i.e. what did I
do last week, what am I doing today, what will I be doing next week).

Four - the requirements of a traditional calendar/scheduling application is
that the server can return to a Calendar User Agent the correct set of
calendar objects. Some CUA's may request the FULL calendar(s) for the user
and expand the RRULES themselves, others may expect just a set of CalObjects
and not perform RRULE expansion (for example in wireless devices it is not
sensible to send a large many year, 1000's of object calendar if the user
just wants to look at next week - but the server does have to send EVERY
object that applies for next week).

Five - this leads to some calendar systems to differentiate between
CalObject with and without RRULES (based on usage observations I think that
MS Outlook is one example of a CUA that segregates object with RRULES).

Six - thus the algorithm's used by a traditional C&S server (or CUA) will
need to be able to check RRULE's against a TIME PERIOD i.e. set mathematics
vs. point mathematics. Time periods are a set of times with two boundary
conditions - each possible CalObject has to in some way be checked whether
it falls within that set.

I have observed a number of Calendar systems that FAIL to do this
correctly - most usually by failing to show events starting on one day but
continuing into the next day on the following day - this implies that the
algorithm used checked only for START times in the period (in this case one
day) and did not look at the duration and/or end times (depending on how the
user defined the event).

I would be interested to know if my observations gel with other members of
this group - and perhaps someone with more formal training in these types of
time mathematics can help with the algorithmic differences and differing
optimizations that are possible for CPL vs. traditional C&S systems.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
Sent: Wednesday, May 16, 2001 10:26 PM
To: 'Shannon J. Clark'; [email-masked]
Subject: RE: RECAP & Questions of CPL RECUR Issues.

-Jonathan R.
---

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 17 May 2001 13:54:23 -0400 (EDT)

> adjusted per the user's timezone settings).

Yes, exactly.  We anticipate there being a small number of rules (but more
than one) per user.  (Timezones actually bind to rules, not to NOW -- NOW is
now (e.g. time(0) on Unix), always.  Note this is in contrast to things like
"TODAY" -- the definition of "TODAY" varies by timezone, so you have to
describe both "TODAY", and the user's rules, by the user's timezone.)

> calendar server's perspective is rarely dealing with POINT TIME issues.

Yes.  I guess the question "who is Joe meeting with right now" is perhaps
occasionally interesting, but hardly the usual case.

> optimizations made possible by these constraints.

Yes.  This is what my code does -- the algorithm is a two-phase operation.
First, "if we were in an event right now, when could it have started?"
Secondly, "is that time actually a valid recurrence time for this rule?"
This is a lot simpler than fully expanding a set.

> so as not to delay the processing of the call.

There are two other interesting properties of CPL vs. the usual calendar
model.  First of all, I imagine CPL rules are much more likely to expand to
huge numbers of events than typical calendars would.  For instance, it would
be entirely probable to have a rule "during working hours" -- in other
words, "9 to 5, Monday through Friday, forever."  This expands to hundreds
of events per year, many more than you'd expect for normal calendar usage I
imagine.  

Another important thing to note is that for CPL you need to have a concept
of the *relative priority* of recurrences.  For instance, you can have a
"during working hours, ring the phone at my desk" rule, and a "during this
meeting, send my calls to voicemail" rule.  If your meeting is during
working hours (as one would hope), there needs to be some way of specifying
which one wins.  In CPL we do this by just letting the rules have a physical
order in the file, and giving them first-match semantics.

One nice side effect of this is that EXRULE and EXDATE can just turn into
special cases of the above ordering semantics.  (With some trickiness (which
I just posted to IPTel about) involving earlier EXRULEs falling through to
later rules, but this is resolvable.)

> CPL will need to deal with

I haven't really thought about this much, but in CPL's model, this is left
up to the client-side, not the server-side.

> do last week, what am I doing today, what will I be doing next week).

Yes.

> day) and did not look at the duration and/or end times (depending on how the

Actually, I don't think set-mathematics vs. point-mathematics are that
different.  The fundamental operation of the point-mathematics algorithm is
"what is the previous possible time this event could have started."  It's
pretty easy to use much the same operations (modulo a few tricky details
involving irregularly-sized units such as months) to instead ask the
question "what is the next possible time this event could start."
Set-mathematics is basically "start at beginning of interval, roll backward
for DURATION checking candidate start times, roll forward to end of set
checking candidate start times."  It's pretty straightforward.  (This is
essentially what I have to do for the COUNT -> computed virtual UNTIL
transformation, and it seems to be reasonably efficient.)

The problem with this is that it doesn't seem to be possible to resolve
BYSETPOS (especially negative BYSETPOS) without actually expanding the set,
which breaks this whole mechanism.

-- 
Jonathan Lennox
[email-masked]