Subject: RE: CALSCH Agenda for IETF 50

From: [email-masked]
Date: Mon, 12 Mar 2001 10:53:11 -0600

> > Six - There is preponderance of sections to the various 
> documents which
> > address the problem set of Scheduling meetings between individuals
> 
> That's because scheduling is where people have the deepest 
> experience; it's the
> problem people set out to solve.  If you want a data model 
> that matches what
> you're doing, please write up a Draft describing your needs.
>
Yep, the original IETF CALSCH effort was chartered to focus on
"interpersonal C&S". 

> > I propose the following - one, the reoccurrence sections - 
> both the simple
> > and the "full" be pulled OUT and turned into a generalized 
> system for
> > reoccurrence rules.
> 
> Very bad idea.  Recurrence rule syntaxes are nasty, twisted 
> little beasties;
> the last thing we want to do is grant them more freedom to 
> proliferate.  It is
> my opinion that we need to rein in the RRULE syntax, and 
> adopt a subset; but,
> even if we wind up supporting both the subset and the current 
> full syntax, I
> would not want to use a generic mechanism that would let 
> people add more in the
> future.
> 
Agree with John about the need for some "interop subsets" of RRULE features.
It is a powerful syntax, but as such is also difficult to find interop
between implementations.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 12 Mar 2001 11:57:35 -0600

What I was trying to suggest is not to make reoccurrence rules proliferate
more freely - but to suggest that it may in fact best be considered
separately from the rest of the standards.

We have already had some suggestions from various participants about
additional uses/issues around reoccurrence rules, additionally they already
make up a seemingly separate set from the rest of the standard - the "full"
syntax is incredibly dense and complex.

There are also many contexts where having a clear means of defining in a
standardized way the reoccurrence of events would be useful - areas which
may or may not incorporate the rest of the CALSCH standards.

	For example - websites displaying information about reoccurring events -
may not be using an iCalendar based system to display it, but rather than
developing a fully proprietary means of calculating reoccurrences reusing
the standard would save significant development time and effort - and
facilitate the eventual movement to an iCalendar based solution. I cite this
from the EXACT case of a client of my company - presently they plan on using
an extracted version of the reoccurrence rules and expect that this will
save many weeks of development time resulting in a much lower cost of
implementation for their web based applications.

Also, just within the context of the standard, there have been proposals to
extend WHERE reoccurrence rules can be employed - some of the suggestions
from the SKiCal group have included this.

Anyway - I guess my main point is that the reoccurrence rules, and the
syntax for them, seem to me to be a separate potential standard from the
base iCalendar standard - as such it seems useful to separate them from the
main standard document and incorporate them by reference - not by embedding
the definition of the one standard into the other.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, March 12, 2001 10:53 AM
To: [email-masked]; [email-masked]
Subject: RE: CALSCH Agenda for IETF 50

---

From: John Stracke <[email-masked]>
Date: Mon, 12 Mar 2001 13:38:53 -0500

> syntax is incredibly dense and complex.

This is a separate issue; I'm working on a Draft to suggest a subset, based on the
work done in CPL.  But it is not useful to have iCalendar with its recurrence
rules; nor is it useful (as far as interop is concerned) to have iCalendar's
recurrence rules without the rest of iCalendar.

> I cite this

> implementation for their web based applications.

Well, but this working group is not here to lower your client's cost of
implementation; we are here to promote interop, so that users can exchange data
regardless of vendor.  From what you say, your client is not doing that; they're
taking the rrule syntax and using it in a proprietary data format, which maintains
vendor lock-in.  Some may consider it gratifying that the rrule syntax turned out
to be useful outside its original domain; but that's not an argument for spending
the working group's time on making it easier to extract.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |If you choke a Smurf, what color does it turn?|
[email-masked]|                                              |
\===============================================================/

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 12 Mar 2001 14:34:36 -0600

Guess this raises a question as far as interop goes. I am strongly
recommending to my client that they use the rrule syntax to PROMOTE eventual
interoperability of the solutions they are having created for them so that
as they move forward they are not locked into a proprietary solution -
rather they can become an ideal client for standards compliant calendaring
software, albeit not calendaring software that is concerned with the
scheduling of people, but calendaring software that is concerned with
conveying timed information to a user population (in this case it is not
public information ala SKiCal but personalized for an individual but not
scheduled with other people).

By employing the rrules directly within their underlying databases and
custom written applications they will greatly facilitate the use of their
information within standards compliant applications.

Thus, I would consider that this use of the rrules to be very much promoting
interoperability, in this case not between different vendors of calendaring
applications, but in terms of helping encourage end user behaviors that help
show the value of interoperability. My client is not interested in writing
software, rather they have information that they are in the business of
sharing with their customers - they want to do this for the widest possible
audience, in a manner that will work going forward, and in a way that
reduces their costs and helps them avoid being locked into a proprietary
solution. By employing the rrules syntax they greatly facilitate converting
their information into native iCalendar information, and from there in
theory they can achieve interop with a wide array of other systems.

I would be curious to hear from others who are working with customers to see
if my conversation with this client was unique or something encountered by
many people - when we are defining interoperability it will only be adopted
by vendors if it provides value to clients and helps drive adoption and
usage of our products - from a vendor's perspective there is a great deal of
value to proprietary processes - they can ensure reoccurring revenues and
client lockin - to push for interoperability there has to be compelling
client driven demands for the value of it. In my client's case it is to be
able to serve the widest possible universe of end users - they do not want
to force technical decisions on their end users, if in the process they also
save themselves time and money so much the better.

Also, I assume you meant to say "If is not useful to have iCalendar withOUT
its recurrence rules" (your original had "with"). I'm not convinced that
this is so - looking both at the majority of the examples in the
documentation, and in many of the areas that calendars are used for,
reoccurring events are by no means the majority of the events handled by
calendaring systems - thus it is quite possible for real usage of a
calendaring system to rarely if ever use reoccurrence rules.

That said, reoccurrence is a very important feature in many situations, it
serves to define a very common situation, and may have some technical
advantages over storing multiple entries. It also has some technical
limitations (such as the issue of how computationally difficult it is to
resolve the rrules in a quick manner).

Reoccurrence is also an area prone to lots of issues surrounding
interoperability - how each system handles exceptions, whether or not the
systems allow for a single instance of a reoccurring event to be modified
(for example a regularly reoccurring meeting - for each specific instance
attaching the current agenda might be a highly desirable action) or the case
of deleting one instance of the series. We are also looking at the various
types of reoccurrences that might be desirable to allow users to use - the
current standards have many more possibilities that it has been said is
feasible to display in a user interface.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Monday, March 12, 2001 12:39 PM
To: [email-masked]
Subject: Re: CALSCH Agenda for IETF 50

> syntax is incredibly dense and complex.

This is a separate issue; I'm working on a Draft to suggest a subset, based
on the
work done in CPL.  But it is not useful to have iCalendar with its
recurrence
rules; nor is it useful (as far as interop is concerned) to have iCalendar's
recurrence rules without the rest of iCalendar.

Well, but this working group is not here to lower your client's cost of
implementation; we are here to promote interop, so that users can exchange
data
regardless of vendor.  From what you say, your client is not doing that;
they're
taking the rrule syntax and using it in a proprietary data format, which
maintains
vendor lock-in.  Some may consider it gratifying that the rrule syntax
turned out
to be useful outside its original domain; but that's not an argument for
spending
the working group's time on making it easier to extract.

---

From: John Stracke <[email-masked]>
Date: Tue, 13 Mar 2001 11:00:03 -0500

"Shannon J. Clark" wrote:

> By employing the rrules syntax they greatly facilitate converting
> their information into native iCalendar information,

So why don't they just use native iCalendar? Why are they taking on the trouble
of implementing iCalendar rrules (the most complicated part) and not going the
rest of the way?

> its recurrence rules" (your original had "with").

Yes, sorry.

> I'm not convinced that

No, but the recurrence rules are iCalendar's largest value-add; the rest of it
is pretty standard stuff that would be easy to work out on your own.

> calendaring system to rarely if ever use reoccurrence rules.

This does not follow.  For example, recurring events make up only a small
fraction of the distinct events on my calendar; but that doesn't mean I rarely
use recurrence rules.  In fact, *instances* of recurring events make up the
majority of the instances of events on my calendar.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |If God had meant us to be in the Army, we    |
[email-masked]|would've been born with green, baggy skin.   |
\==============================================================/