[Ietf-calsify] What's wrong with more radical simplification?

[Nathaniel Borenstein]

Tim Hare said something in October that was so on target that I think 
it's worth reading again:

> Maybe it's serendipity, but I was pointed to an old post at 
> http://www.shirky.com/writings/evolve.html about evolvable systems as 
> it relates to the Web; and it kind of struck a chord about what we're 
> doing here.
>
> Let's get out an iCal-Basic that everyone can create easily from what 
> they've got now,  and everyone can read in with what they've got now. 
> Even if it means we're passing back-and-forth larger sets of data to 
> describe repeating appointments, even if it means certain appointments 
> that cross timezones or daylight-savings-time changes have problems.  
> The thing is, if we can get out something that works, we can then 
> evolve it to work better.  We have got to find the simplest common 
> denominator that works, call that iCal-Basic, and release it. That's 
> the four-footed fish crawling up on the shore... we'll get to mammals 
> later.

I believe this post goes to the heart of everything that is most broken 
about iCal, and that we must take it very seriously if we're to have 
any hope of fixing this mess.  I will therefore reiterate yet again my 
past observations about the potential for radical simplification, 
simply because no one has yet convinced me that what I advocate would 
be an *over* simplification.  I believe that we should grab for any 
simplification that won't demonstrably make the standard inadequate for 
its primary purposes, which I regard to be personal and interpersonal 
event scheduling.

I still believe that we can completely eliminate recurrence rules, and, 
given that elimination, we can radically reduce the importance and 
complexity of time zones as well.

First of all, let's consider carefully what will happen if we choose to 
go down the road, as many are proposing, of making RRULES an optional 
part of the specification.  In that world, the composer of an email 
invitation to a repeating meeting won't be able to know (for reasons 
touched on in my companion post, "Receiver Capability Description 
Considered Harmful") whether or not the recipient(s) will understand 
RRULES.  Thus, such a composer will inevitably end up sending repeating 
meeting invitations as multipart/alternatives, containing both a "set" 
and a "rule" description of the repeating meeting.  In that case, I 
would argue that the RRULES can be dispensed with entirely as 
redundant.

Eliminating RRULES implies, in turn, that we can use UTC for nearly 
everything, so that the only time zone translation that needs to be 
done is at the user level and involves the relatively straightforward 
translation between UTC and the user's own time zone.  Together, this 
pair of changes would be an enormous simplification of a protocol that 
I believe is choking under its own complexity.  Even the discussion on 
this list about how to simplify RRULES is, I fear, too complex for many 
potential implementors to understand, and thus will inevitably lead to 
"misinterpretations."  (I put the word in quotes because I believe that 
if there is any way to misinterpret a standard, it is the spec that is 
at fault, not the implementor.   Long experience has taught that if 
there is more than one way to interpret an RFC, it will be interpreted 
in more than one way by software that claims to be conformant.)

If, as I am claiming, it is *possible* to do everything without RRULES, 
and that RRULES are just a bandwith-and-space-saving-convenience for 
repeat meetings that have LOTS of repeats (and, of course, a truly 
vital feature for any imaginary meetings that continue infinitely, 
unlike their attendees), then we should try to build a complete version 
without RRULES first, and only try to add on the efficiency/convenience 
of RRULES later, if at all.  Worrying about the cost/efficiency of 
representing a recurring meeting, in a world full of BitTorrent and 
webcams, strikes me as rather myopic.  If we can live with base64, we 
can live with this.

I know that several of you are tired of hearing this argument from me.  
I encourage you to shut me up by convincing me that it is NOT possible 
to define a completely adequate version of iCal that doesn't have any 
recurrence rules.  But if it is possible, I think it is what we should 
do. -- Nathaniel