[Ietf-calsify] Re: RRULEs

[Chris_Stoner at notesdev.ibm.com]

Doug Royer  wrote on 08/17/2004 02:53:31 PM:

> >I disagree.  I think Rules should go.  Why not take out the complexity
of
> >recurrences and have the standard dictate that the vendor must send a
list
> >of dates, and optionally send a recurrence rule (for UI purposes or
maybe
> >for handheld devices)?  This way the recipient does not have to infer
what
> >the rule meant, but can simply put the sent dates on the calendar.
> >
> Standing staff meeting every Monday at 2pm. The argument for not being
able
> to have unbounded instances is the problem. What limit? How many means
> forever?
> Or do we add a new unbound property or parameter. Then we are back to
some
> version of rrule.
>
> Currently multiple RRULE properties are allowed per object. I think that
> needs to go at a minimum.

Yes - infinitely recurring meetings would no longer be supported. There
would simply be no way to express that in a list of time/dates, unless, as
you said, we fell back to sending a rule as well.

What about just getting rid of infinite recurrences?

> >I really think this is worthwhile to consider if you take it step
further -
> >to reschedules.  This is where each vendor does their own thing
> >(currently).  That's ok, so long as we're all sending the same basic
data,
> >but we're not.  If we sent the exact dates that we want rescheduled, and
> >the exact dates that we want rescheduled to, we'd solve alot of basic
> >rescheduling interop problems.
> >
> Yes. TOSS all of the iTIP complexity. Simply send replacement objects.
> That's one
> method of updating objects that works for all vendors already. Keep the
> same UID
> and update the SEQ values, send new objects. Simplifies all of that mess.

Right - and think of this: the vendor can still have multiple Rules,
exceptions, etc. in their UI, but what they send has to be the
consolidation of all of that in a list of time/dates...
-CS