Subject: [Ietf-calsify] Another issue - reschedules and recurrences

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Wed Aug 18 12:36:58 2004

It seems like we should leave it up to client applications what to do
with past meetings that receive an update for the recurrence.  However,
I think the standard should continue to allow it.  I want to change my
team meeting to wednesdays instead of tuesdays, and extend it to the end
of the year - I'll send an update to do so.  The old appointments could
either be carved in stone (since they are past) and stored as a kind of
static history, or altered to reflect the new recurrence pattern
depending on the sophistication of the client.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 18, 2004 10:50 AM
To: [email-masked]
Subject: [Ietf-calsify] Another issue - reschedules and recurrences

Should we allow recurrences to grow on a reschedule?  The standard
currently allows for this - simply send a new rule (or list of
time/dates if we went that route - doesn't matter).  The Rule example
can have a different number of occurences than the original meeting.

Should we make this more clear?  If you want to grow or shrink the
number of occurences, should be send the recipient more information,
like which ones from the old set to keep (if any).  There might be
different room or body information on the old set that the sender might
be intending to preserve and just move around on the calendar.
-CS

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

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Wed Aug 18 12:52:20 2004

I still think there's a problem with that.  Just sending out a reschedule
that can both add on new dates to the meeting *and* remove some old dates
(new Rule is a good example) can be hard for  vendors to figure out what to
do with.  Which dates to keep?  Which dates to move?  Which dates to
cancel?  There's too much going on there I think.  I think there's a
general issue with iCal that it's often hard to figure out - what did you
mean when you sent this?

A better solution, imho, would be to have dates removed be cancels and
dates added as some other form of action.  This way the cancel case and the
regular reschedule case follow simple rules - look up the UID of the
meeting, the recurrennce ID and move/cancel that one.  Adding on to an
existing meeting could simply be another invite with the same UID and
recurrence IDs that never existed before.
-CS

"Cameron Stillion" <[email-masked]> wrote on 08/18/2004