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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Thu Feb 10 09:44:13 2005

While I agree with you philosophically, I believe there is also a
practical issue to consider:  Any standard which has meaning must have
some relevance to the working products that are in frequent or popular
usage.  If we were in a state where no product or vendor had yet
released significant support of iCal, I would agree with you completely.
However, there are products now shipping and becoming more commonplace
that we must also consider.  Apple's iCal (who came up with that
original name?) product and their .mac service that hosts published
calendars.  Mozilla's product that reads and writes iCal format, and
several others - some already out there, and some on the verge of
releasing... There are other web services (I use the term loosely, not
in the MS.NET sense) that have sprung up around iCal: icalx.com,
icalshare.com, and others...  A standard which these products and
services do not use is (imho) not all that meaningful.

To hit on some of your specific points: removing rrules would not affect
the apps and services that use them currently.  Frankly, I can't imagine
removing support for rrules in our current product, or generating icals
without them.  It would mean more "lossy" conversions, not less.  I
can't imagine other vendors doing it either.  Perhaps new systems could
opt for the "simpler" rrule-less standard, but then they would be
incompatible with the existing big dogs that use this technology.  In
some ways, we are dealing with the tyrrany of schema - you can't take it
back, once it is commonly used.  You can deprecate it, provide a better
replacement, but it is VERY difficult to stop supporting it.

I believe that to be successful, we must capture the state of the art
that is happening today, perhaps with some tweaks to the more difficult
aspects that thwart integration and interoperability.  Radical
simplification to the standard make it theoretically easier for entrance
to the game, but I think the sweet spot here is to capture what's
already being played, and then to move on from there.  A Diet-iCal may
very well be useful to embedded systems or small devices (maybe) in the
future, but I don't see it as our most pressing objective, or our most
promising one.

Thoughts?

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nathaniel
Borenstein
Sent: Thursday.10.February.2005 08.29
To: [email-masked]
Subject: [Ietf-calsify] What's wrong with more radical simplification?

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

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: tantek at technorati.com (Tantek Çelik)
Date: Thu Feb 10 11:24:28 2005

+1 on what Cameron Stillion wrote.

If the choice is between defining iCal as:

  1. maximum interoperability profile of existing major/popular 
implementations
  2. minimum possible useful profile (radical simplification)

 From following all the discussions in this thread, and considering 
practical matters of current implementations and market forces (e.g. if 
current implementations interoperably output RRULES, then any new 
implementation will be forced by market forces and competitive pressure 
to accept and support RRULES), 1. seems like the only realistic choice.

Tantek

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Thu Feb 10 12:02:27 2005

+1 for Cameron's thoughts.

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb

---

From: pregen at egenconsulting.com ([email-masked])
Date: Thu Feb 10 14:59:44 2005

Hi Cameron.  I agree as well.  However, one of the biggest problems we see 
are different implementations of the standards out there.  One product 
uses the very first implementation of vcalendar or icalendar and others 
use the later versions.  So, even within the standards that are out there, 
we have collisions. 

That's one of the reasons I am so excited about the Min-IOP Technical 
Steering committee work that's coming out of the Calconnect consortium. If 
we can identify what is the lowest common denominator where the majority 
of the calendaring applications work today - we have our ical-lite.  Then, 
we can carve away the pieces that dont' work (timezones and recurrence 
rules - although some things do indeed function - just not all) and make 
them either ical-extensions, or whatever, who cares.  But getting 
something we know will work with Outlook, Lotus Notes, Mozilla, Yahoo, 
Isamet, Oracle, whatever, makes me, a calendaring user from way back, 
pretty excited.  As it does my clients as well.  8-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
02/10/2005 12:43 PM

To
"Nathaniel Borenstein" <[email-masked]>, 
<[email-masked]>
cc

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

Thoughts?

cameron

---

From: pregen at egenconsulting.com ([email-masked])
Date: Thu Feb 10 15:00:39 2005

I responded before but want to make sure my count is in.   +2 for Cameron
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Mark Swanson <[email-masked]> 
Sent by: [email-masked]
02/10/2005 03:02 PM

To
[email-masked]
cc

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

---

From: tantek at technorati.com (Tantek Çelik)
Date: Sat Feb 19 19:05:39 2005

I want to re-raise the issue of what is the scope of iCal-Basic because 
I feel that has been lost with the deep-dive into the RRULES 
discussion.

See 1. max-interop vs. 2. min-useful in previous email below.

Another example of  max-interop vs. min-useful is perhaps DTEND.

A max-interop evaluation of DTEND would ask the question of how 
inteoperable are implementations of DTEND.  I don't know the actual 
answer offhand, but I can only surmise that a property so simple would 
be quite interoperable (please correct me if tests have shown 
otherwise).  Therefore DTEND should be included.

OTOH, what is in *-02.txt is perhaps the min-useful perspective, which 
asks whether  DTEND is necessary, and finds that it is not, since 
DURATION can simply be used instead.  Therefore DTEND was removed (or 
in this case deprecated).

However, for the same reasons as before:

  " if current implementations interoperably output feature XYZ, then 
any new implementation will be forced by market forces and competitive 
pressure to accept and support feature XYZ"

I still prefer 1. max-interop and thus prefer to keep DTEND (without 
deprecation).

Regards,

Tantek

P.S. One could make the additional argument that whether a VEVENT has a 
DTEND
or a DURATION could be used to keep track of whether the *user* 
specified a duration or an absolute end datetime for an event in their 
calendar user interface, and thus DURATION can't serve as a 100% 
replacement for DTEND.  This is merely a theory, I don't know of any 
actual implementations that treat DURATION/DTEND with this particular 
detail.

On Feb 10, 2005, at 11:23 AM, Tantek ?elik wrote:

> practical matters of current implementations and market forces (e.g. 
> if current implementations interoperably output RRULES, then any new 
> implementation will be forced by market forces and competitive 
> pressure to accept and support RRULES), 1. seems like the only 
> realistic choice.
>
> Tantek
>
>
>

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Feb 20 21:57:11 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050220/0903b8ae/smime.bin