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

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Thu Mar 10 09:50:12 2005

Well, here it is two hours before the BOF and I'm finally catching up 
on the email, but I can't resist commenting on this:

Am Samstag, 12. Februar 2005 02:26 schrieb Tim Hare:
 > ... I want calendaring to be just as simple as e-mail is now -

On Feb 12, 2005, at 4:39 AM, Reinhold Kainhofer wrote;
 > Hehe, you chose the wrong example here. Do you know how complex the
 > specification for email is (in particular the mime spec and all the 
various
 > encodings possible)? iCalendar is trivial compared to those specs...

Actually, the reality is both more interesting than this *and* 
potentially a model for the current situation.

In designing MIME, we were faced with an incredible complexity of 
potential uses and applications.  As such, we largely retreated from 
specifying formats for *any* of them.  Instead, we focused on basic 
syntactic and encoding requirements for a tremendously extensible 
format, defined a few core types that we thought were obviously 
necessary, and left the rest to be done as future extensions.  By now, 
a paper copy of all the MIME extension specifications would probably 
come in multiple volumes (and would, of course, include all the iCal 
specs).   I am rather glad that we didn't try to do all that work in a 
single specification!

I see the ongoing work of data format specification as being, for all 
intents and purpose, fractal.  Whatever we define today, people 
tomorrow will be trying to extend it in multiple, unforeseeable 
directions.  The wisdom of the 80/20 rule is that it is a good 
heuristic for working with fractally complex problems:  1.  Solve 80% 
of the problem facing you.  2.  Look deeper at the remaining 20%.  3.   
Return to step 1.  (It doesn't always work, you have to break out of it 
occasionally, but it's a good default strategy.)

In the case of the ical standards, we have a historical failure to 
follow this model; the format tried to do so many things that it had 
trouble clarifying even some simple ones.  Thus, our current dilemma.  
I don't doubt the need for some way to express recurrence.  I do doubt 
that there is a simple or obvious solution, or even that there is a 
single solution; in the long run, we may need multiple languages for 
specifying RRULES, to support non-Western or non-Terran calendars, for 
example.  But we're not qualified today to plan the details of working 
with the Ganymede Colony's calendaring system.  Thus, when I pipe up 
about getting rid of recurrence entirely, what I'm really saying is 
that this is what we should have done in the first place, and only 
started worrying about specific recurrence types (as opposed to the 
general architectural notion of recurrence) once we had done a good job 
of the initial 80% of the problem (including the architectural place of 
recurrence and other "extension" mechanisms).

Our current "cleanup" efforts should at least try to approximate the 
results of having done things in a more evolutionary manner.  That's 
hard to do, because you almost want to "unlearn" some of the things you 
think you already know you need while focusing on the core.  But I 
think it's our best hope for clarity and consensus.  -- Nathaniel

---

From: TimHare at comcast.net (Tim Hare)
Date: Sat Mar 12 06:24:49 2005

Since I am a "quotee" I feel compelled to clarify my comment: I fully 
understand the underlying complexity of things (I work with z/OS for 
example, and I have in the past supported OfficeVision/MVS a very model of 
medium complexity). What I meant by my comment was: people just "walk up to 
e-mail and use it" now, they don't think about it so much (because so many 
developers thought about it and worked on things like MIME); calendar 
should be that way - people should use it intuitively.

Nathaniel used the phrase "recurrence type" - and maybe that's an idea... 
we've been thinking of various levels of iCalendar, but maybe for 
recurrences we want the object to identify its own level?  For examples:

  RRULE;RTYPE=Mars-Syntax: {Some syntax defined by those angry Martians who 
didn't like the basic one}
  RRULE;RTYPE=Ganymede-Syntax: {Some syntax defined by the Ganymedians 
(and/or their pals the Ganymeans and Ganymaximums but I digress)}
  absence of RTYPE implying RDATEs only

It does NOT improve simplification, so should be in a higher-level 
iCalendar, but perhaps it does improve the recurrence rule problem? There 
would also need, in iTIP or follow-on, need to be a response meaning "I 
don't get this syntax".  Maximum implementations could send the recurrence 
rules in several (perhaps the most popular in terms of sales) syntaxes at 
the same time since the receiver would pick only the syntax they'd like.

And now for something completely different:

Should we be careful to use iCalendar in our posts rather than iCal to 
avoid confusion with Apple's product? Not for copyright/trademark concerns 
but I'd like to be clear about what iCalendar the protocol/format does 
versus what iCal the product does with it.

And last but not least: I've lost some e-mail due to a computer failure. 
There's one issue from Calsify that I would like someone to explain to me 
OFF the list, if they would:  Why, in an iCalendar-Basic using only UTC 
times, would timezones matter on recurrence rules with participants in 
different timesones/daylight savings time areas? I seem to recall some 
discussion, and a valid reason, but I can't remember it and I'd like to. 
So, if anyone has a concise explanation, please send it to me... thanks.

At 12:50 PM 3/10/2005, Nathaniel Borenstein wrote:
>Well, here it is two hours before the BOF and I'm finally catching up on 
>the email, but I can't resist commenting on this:
>
> > specification for email is (in particular the mime spec and all the various
>Actually, the reality is both more interesting than this *and* potentially 
>a model for the current situation.
>
>syntactic and encoding requirements for a tremendously extensible format, 
>defined a few core types that we thought were obviously necessary, and 
>left the rest to be done as future extensions.  By now, a paper copy of 
>all the MIME extension specifications would probably come in multiple 
>volumes (and would, of course, include all the iCal specs).   I am rather 
>glad that we didn't try to do all that work in a single specification!
>
>intents and purpose, fractal.  Whatever we define today, people tomorrow 
>will be trying to extend it in multiple, unforeseeable directions.  The 
>wisdom of the 80/20 rule is that it is a good heuristic for working with 
>fractally complex problems:  1.  Solve 80% of the problem facing 
>you.  2.  Look deeper at the remaining 20%.  3.
>In the case of the ical standards, we have a historical failure to follow 
>this model; the format tried to do so many things that it had trouble 
>clarifying even some simple ones.  Thus, our current dilemma.
>that there is a simple or obvious solution, or even that there is a single 
>solution; in the long run, we may need multiple languages for specifying 
>RRULES, to support non-Western or non-Terran calendars, for example.  But 
>we're not qualified today to plan the details of working with the Ganymede 
>Colony's calendaring system.  Thus, when I pipe up about getting rid of 
>recurrence entirely, what I'm really saying is that this is what we should 
>have done in the first place, and only started worrying about specific 
>recurrence types (as opposed to the general architectural notion of 
>recurrence) once we had done a good job of the initial 80% of the problem 
>(including the architectural place of recurrence and other "extension" 
>mechanisms).
>
>results of having done things in a more evolutionary manner.  That's hard 
>to do, because you almost want to "unlearn" some of the things you think 
>you already know you need while focusing on the core.  But I think it's 
>our best hope for clarity and consensus.  -- Nathaniel
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc.