[Ietf-calsify] Another issue - reschedules and recurrences
camerost at exchange.microsoft.com
Thu Aug 19 09:15:32 PDT 2004
Yep, it is hard to figure out what to do. Outlook, for instance,
deletes all of the old instances, loses all conflicts, and
re-establishes the meeting at the new recurrence locations. Not pretty,
but in the end you have what you asked for (albeit a bit brutally).
There is a user model here that is not quite clear. When you are
changing a meeting significantly, do you simply truncate the existing
one and create a new one? Or, do you munge the old one beyond
recognition? It seems rather repugnant to simply exclude every instance
of the appointment and include a secondary recurrence that accurately
represents the meeting. But I'm not sure we should enforce either
behavior. The user does whatever they will do.
Perhaps the underlying storage should even support both approaches (it
does now). Smarter clients though, could avoid changing past
recurrences using exceptions (let's hope there aren't too many) and
create new (future) recurrences using the updated recurrence info. Can
we leave this decision to the clients?
This seems less of a schema/interop issue than a client decision.
From: ietf-calsify-bounces at osafoundation.org
[mailto:ietf-calsify-bounces at osafoundation.org] On Behalf Of
Chris_Stoner at notesdev.ibm.com
Sent: Wednesday, August 18, 2004 12:44 PM
To: ietf-calsify at osafoundation.org
Subject: RE: [Ietf-calsify] Another issue - reschedules and recurrences
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.
"Cameron Stillion" <camerost at exchange.microsoft.com> wrote on 08/18/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.
> -----Original Message-----
> From: ietf-calsify-bounces at osafoundation.org
> [mailto:ietf-calsify-bounces at osafoundation.org] On Behalf Of
> Chris_Stoner at notesdev.ibm.com
> Sent: Wednesday, August 18, 2004 10:50 AM
> To: ietf-calsify at osafoundation.org
> 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.
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
Ietf-calsify mailing list
Ietf-calsify at osafoundation.org
More information about the Ietf-calsify