Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts so far

From: TimHare at comcast.net ([email-masked])
Date: Tue Aug 17 20:43:05 2004

If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps 
you're on a path where you have a multi-layered standard:

         Layer 0 would be representation of the "generic" parts of the 
object (DTSTAMP, UID, DTSTART(?) etc.)
         Layer 1 would be representation of specific items, perhaps one 
standard per VEVENT/VTODO/VJOURNAL, etc.

Endpoints of a calendaring conversation would have to either identify what 
objects they could deal with, or issue errors when passed an object they 
couldn't, or both.

Elimination of recurrence rules by passing lists of date/time values back 
and forth overlooks the advantage of using the "shorthand" of recurrence 
rules, which allow a large list of dates and times with a short rule. I'm 
not arguing for or against, just making a point that I hadn't heard 
expressed.  If you end wanting both possibilities, you have to have a 
discovery mechanism to see what the other end handles. This, I think, is at 
least partly handled by the "expand recurrence" property which is returned 
in the GET-CAPABILITY response (I think).

Elimination of GEO values - I would rather see GEO be used as an index into 
timezone data, rather than passing the timezone data along with the 
objects, since a geographic location rather efficiently can get you the 
timezone information. If eliminated, then I would like to see another 
document for standardization of time zone identifiers, and only pass the 
identifiers, not all of the time zone rules themselves.

Tim Hare
Interested Bystander, Non-Inc.

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Wed Aug 18 08:30:57 2004

On Tuesday, August 17 2004, "[email-masked]" wrote to "[email-masked]" saying:

> rules, which allow a large list of dates and times with a short rule.

The other big advantage of recurrence rules is editability.  If you've got
an event with a rule that says "every Tuesday at 4:00", it's easy to edit
that into "every Wednesday at 11:00".  Clients have to be a whole lot
smarter in order to figure out that a long list of occurences, all of which
happen to fall on Tuesdays at 4:00, should be changed in a bunch.
(Basically, in order to edit events as a group, clients would have to
reverse-engineer RRULEs from event sets.  This seems like it could be a
nightmare for interoperability.)

That said, I'm definitely in favor of simplifying RRULEs.  (People may be
aware that I'm the author of the Call Processing Language, which re-uses
iCalendar's RRULEs to specify periods of time for time-of-day call routing.)

One property I'd very much like to see in a simplified RRULE spec: given an
RRULE and a period of time, it should be possible to determine what
instances of the RRULE fall within the period, without having to expand the
RRULE.  (I *believe* this is possible if you just eliminate COUNT and
BYSETPOS from the RRULE spec; but there are enough ugly corner cases that
I'm not positive my algorithm is correct.)

> identifiers, not all of the time zone rules themselves.

This ought to be coordinated with the TZ list <[email-masked]>, which
maintains the Olson timezone database, the de-facto Unix standard.

-- 
Jonathan Lennox
[email-masked]

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Sat Aug 21 16:10:44 2004

I'd like to suggest a somewhat more nuanced view of the role of 
recurrence rules.

I suspect at this point we might all agree that the current recurrence 
rules have two rather different kinds of problems -- problems that stem 
from the recurrence rules being "too complex" (as one gets into complex 
exceptions, etc.) and problems that stem from the recurrence rules 
being "too simple" (for expressing ever-more sophisticated types of 
recurrences, including recurrences in other calendar systems).

The fact that there are problems in both directions suggests to me that 
we are dealing with two rather different kinds of requirements, and 
that we'll make better progress if we can identify them and perhaps try 
to separate them.  I think the answer is that the "user to user" 
description of a recurring event can and should be very different than 
the "server to server" representation of that event.

Obviously, in calendaring and scheduling work we often need to describe 
a "recurring" (or "multiple date") event, and we've been trying to 
express all of that with a single language.  But the fact is that we 
need such descriptions in two very different circumstances:  when 
communicating with the  user, and when communicating with other 
calendaring software.  I think our problems begin from trying to use 
the same language for both.  There is a near-infininte number of 
potential user-level abstractions (events that recur on the 
next-to-last Thursday of the month, on the first Tuesday after the 
first Monday, at the full moon, during Lent, on Jewish or Islamic 
holidays, and so on.)  Trying to encode them all in a transport-level 
standard has led us into the current situation, where we have the 
paradox of an event representation format that seems at the same time 
to be overly complex and representationally inadequate.

So lets back up a minute.

As one with a strong "KISS" instinct to completely throw away 
recurrence rules, I am nonetheless taken by an idea that I think 
started with Chris Stoner:  make the rules truly optional.  Fleshing 
the idea out a bit has taken me a while, but...

I would propose that we need to be able to exchange TWO representations 
of a recurring event -- basically sets and rules, with a requirement 
that the set always be provided, at least in asynchronous protocols.  
(A capabilities-exchange might be able to relax this requirement for 
CAP or CALDAV, but let's leave that for another message.)

Thus, when I send you a multiple event representation via email, I will 
*always* send you the event as a set of dates, and I *may* also send 
you a rule-based description of the event.  However, if I send you the 
rule-based description of the event, I *must* also send you a string 
indicating which rule description language I am using.  In other words, 
we can begin to evolve *multiple* rule-description languages.

How does that help?  Well, first of all, it reduces the minimal 
implementation -- on the receiving end, you can always ignore all rules 
if you're so inclined.  Second, it explicitly separates the two aspects 
of the problem mentioned above, and puts all the user-facing variance 
into the rules, which not every implementation needs to understand each 
language for, but still permits "consenting" calendars to preserve 
user-level semantics.  (Thus if your recipient and you both have 
calendar systems that support the "Islamic calendar rules" they can 
provide you with a shared user-level concept of "Ramadan" but if your 
recipient's system lacks that capability, it can still identify the 
days that constitute Ramadan this year.)  By making the rule language 
extensible, we gain a graceful path to gradually widening the circle of 
user-level semantics that we can represent.

Of course, the one thing that we can't properly represent this way is 
an infinitely recurring event.  While I still contend that infinitely 
recurring meetings are bad things, we can still have rule languages 
that describe them, if we augment the specification of a "set" to 
indicate, for example, that this is just the next 5 years of an 
infinite meeting, so that at least set-only implementations will know 
what kind of information they are losing.

Let me make this more tangible:  Consider a meeting that takes place 
every Thursday, forever.  Imagine that the "rule language" that I, as 
an calendar implementor, prefer is called "Unix Cron" -- i.e. you can 
specify recurring events in Unix cron format.  (NOTE:  I do not 
recommend that language, I'm simply choosing it as a very simple 
example with which many people are familiar.)  By encoding the meeting 
as the rule "* * * * 4" in the language "Unix cron" you ensure that any 
other calendar system that understands Unix cron format will get it 
exactly right.  Then you also include, in any data that you send 
(again, at least any data you send asynchronously) a list of all the 
Thursdays for the next 5 years, along with some (to be determined) 
additional syntax that says, in essence "this is an infinite meeting 
that has only been enumerated from 1/1/05 to 1/1/10."  A receiving 
system that didn't understand the "unix cron" language could still make 
a note to itself to look into this (e.g. via CAP/CALDAV/whatever) in 
July of '09.

I know that the idea of a potentially unbounded set of rule description 
languages is daunting, and I would hope the set would remain quite 
small.  But I think that this additional cost in "edge complexity" is 
more than offset by the significant reduction in complexity for a 
minimal implementation.  I look forward to other perspectives -- or in 
other words, fire away!  -- Nathaniel