Subject: Re: Additional RECAP and status of CPL RECUR Issues.

From: "David L. Nicol" <[email-masked]>
Date: Wed, 08 Aug 2001 16:36:35 -0500

"Shannon J. Clark" wrote:

> The concept of a "simple" list of the other occurrences of an event -
> while seemingly simple - gets really really ugly fast if you have to deal
> with any of the following - events that recur "forever" (the Monday morning
> conference call);

In the paper and ink, squeaky-file-cabinet world, you rarely have more than
12 months of paper calendar.  Even in extended situations, events are
maintained by users or user agents, who might, for instance, take an hour
in
September to pencil all the monday morning conference calls into next
year's
paper calendar.  That's where the division traditionally has been between
CS and CUA -- the CS only looks so far ahead, and the calendar user notes
the recurring events as far into the future as the CS supports.

The situation immediately deuglifies if you allow the user software to be
responsible for the events that recur forever.  specifying 52 events takes
less bandwidth than this letter.

Bandwidth has traditionally kept up with processing power: unless
we're dealing with an expensive link, conserving it is questionable.

>  events that are LOCAL and REOCCURRING - thus the "time" of
> each reoccurrence might be dependant on a user's timezone settings (and
> further complicated by Daylight savings shifts that result in the possible
> case of events "reoccurring" on a non-existent time; Events with a large
> reoccurrence set - for a simple example an entry on a calendar intended to
> define my "work days" for the year - could be entered easily as an event
> that reoccurs from 9-5pm Mon-Fri having a set of exceptions mapped to my
> client's holidays - even bound to one year - this event could have a simple
> RRULE w/10 Exceptions - or if enumerated will over 200+ dates in a list -
> probably increasing the size considerably.

A complex compliant CS could take the 200 dates in either
compact or expanded form, a simple one would insist that they be
pre-expanded.  I hope my suggestion did not sound like I was suggesting
that recurrence rules should be eschewed -- merely switched from MUST to
SHOULD
status (not sure where they are now) -- so a CS that did not implement them
could still be compliant.

> Two - on the related concept of removing RRULES to a degree from RFC2445 - I
> think this is a GOOD idea - my suggestion would be to define the RRULES in a
> SEPARATE standards track - one that is very much tied to RFC2445 (but no
> solely defined therein) - this allows the RRULES to be applied in a clean
> fashion to other programs requiring Temporal Reoccurrences (such as
> Caches) - without adding the scheduling/meeting infrastructure and overhead
> of iCalendar.

Another obvious but necessary example might be a rewrite of Vixie cron.

-- 
                                           David Nicol 816.235.1187
free Dmitry Skylarov

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 8 Aug 2001 17:08:42 -0500

I agree that CUA could do this - HOWEVER it "feels" highly non-conducive to
interoperability and very much prone to information drop-offs.

For example - if a CUA is designed to keep things accurate for the next 12
months - or ANY arbitrary period - then requests just OUTSIDE of this window
will be dealt with in an INACCURATE manner.

	That is - if the CS is working just by storing an expanded list - without
reference to an RRULE set as well, then it has no means of knowing that an
event is "going to" be set for a given time in the future - in a paper world
this is perhaps less critical since you rarely are dealing with events into
the future - but consider how networked calendaring systems could reshape
how things are planned and organized:

	Simple example - wouldn't it be quite powerful if when planning a
conference for example - (a year or two out perhaps) - the planner could
"publish" the event and receive back feedback from the many potential
speaker's calendar servers - perhaps indicating commitments a year or two
out.

	Now extend this to include the schedules of all of the following: media,
members of the organization (and their corporation's schedules), and
sponsors - such a system could potentially allow for better attendance and
more productive events.

To accomplish this (which could easily involve the exchange of many messages
across many different implementations of iCalendar/CAP based calendar
servers it is probably vital that all involved have the ability to present
as accurate as possible a view of the ARBITRARY future - that is that when
queried for FREE/BUSY information or when processing a published event the
CS can reliably deal with a non-bound point in the future. Any system that
is dependant on the CUA for "keeping it up to date" is one that CAN NOT meet
these requirements - a list of 52 events and a "promise" to add additional
events on some fixed interval is NOT the same as the CS store having the
information required to "know" that the event reoccurs forever - this
requires that the CS has some means of "knowing" that at any point in the
future - should that point intersect with the repetition pattern of a
particular event that event will occur on that date.

This does require some computation on the part of the CS - at some point -
one option that is not ideal but probably acceptable even in the complex
model I described above is to extend repetitions out past the boundaries
that a CS will function on (for example many Unix based systems might choose
not to deal with ANYTHING after 2037 due to Unix time stamp y2037 issues...
in this case there is a cutoff - but the whole system does not function -
which is probably cleaner than returning invalid information (i.e. a NO
INFORMATION POSSIBLE/OUT of BOUNDS message is more meaningful than a message
saying "NO CONFLICTS" but returning "CONFLICTS" when queried a bit later.

Also, there is a further issue of precedence and order of operations - in
this type of scenario say that reasonably enough you want to have certain
behavior should you be scheduled for two events at the same time - this
could be as simple as the order to display the events or as drastic as an
automated rule to send a "not attending" message on events that arrive in
conflict.

Should a system with reoccurrences maintained by a CUA give precedence to
the event vs. a new conflicting event? How would this work? When the second
conflicting event arrives the time in question might be empty of conflict -
since the CUA could have not yet caught up to that point in time - then when
the CUA does attempt to "catch up" should the conflict trigger conflict
related behaviors? Should it trigger a message back to the second
conflicting event's organizer saying "sorry - can't come?"

This is one of the types of problems I thought electronic calendaring and
scheduling systems were designed to solve - to get us all out of the problem
of "forgetting" that something that is always reoccurring would be
reoccurring at a particular point of time in the future - whether it is the
Monday morning conference call that always happens, or the options
expiration day etc - the point is that calendaring and scheduling systems
are intended to get users away from conflicting messages about a given
future event - by allowing for the future to be partially mapped out!

Shannon

-----Original Message-----
From: RFC850 host name inserted by qmail-smtpd
[mailto:[email-masked]]On Behalf Of David L. Nicol
Sent: Wednesday, August 08, 2001 4:37 PM
To: Shannon J. Clark
Cc: [email-masked]
Subject: Re: Additional RECAP and status of CPL RECUR Issues.

--
                                           David Nicol 816.235.1187
free Dmitry Skylarov

---

From: "David L. Nicol" <[email-masked]>
Date: Wed, 08 Aug 2001 17:36:41 -0500

> speaker's calendar servers - perhaps indicating commitments a year or two

How about, the CUA tracks the end point that a CS is promising to maintain
information until, perhaps this is even part of the CS's greeting:

	Hello, I'm calendar.umkc.edu, maintaining dates until Mon 2011-Aug-08

and the CUA expands the RRULES it is tracking, as the date recedes?

> . Any system that
> information required to "know" that the event reoccurs forever

Standards should be inclusive.  I think there's a standard that says that.

> saying "NO CONFLICTS" but returning "CONFLICTS" when queried a bit later.

Agreed.  Does the current draft contain an error code for this situation?

> automated rule to send a "not attending" message on events that arrive in

This sounds like an implementation detail, dealt with by a good calendar
interoperability standard at best by providing a channel for
implementation-specific
settings.

Currently the draft says that extensions may not ship.  That sounds to me
like a rule that is set up to be broken.

> conflicting event's organizer saying "sorry - can't come?"

These make sense as implementation and user preference issues, not part
of a standard.

> Shannon

The desire to have your servants plan your day is certainly understandable,
but I'd rather have mine present me with a menu of options and play my
priorities
by my mood of the moment.

Prioritization of events feels like it belongs in the UA not the S; and if
so programmed, having the UA preprocess all the events and set your
availability
makes more sense to me than insisting that only one style of personal
organization
is supported by a standard.

Standards are supposed to be inclusive.

-- 
                                           David Nicol 816.235.1187
"Tomato!"