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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Thu Aug 19 09:15:32 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.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 18, 2004 12:44 PM
To: [email-masked]
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.
-CS

"Cameron Stillion" <[email-masked]> wrote on 08/18/2004
03:36:53 PM:

>
> 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

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