Subject: [Ietf-calsify] Issue 62: RECURRENCE-ID

From: gafter at google.com (Neal Gafter)
Date: Wed Feb 7 15:17:53 2007

On 1/26/07, Eliot Lear <[email-masked]> wrote:
>
> Issue 62 says the following:
>
> > In section 4.8.4.4 Recurrence ID of RFC 2445 it says:
> >
> > > When the definition of the recurrence set for a calendar component
> > > changes, and hence the "SEQUENCE" property value changes, the
> > > "RECURRENCE-ID" for a given recurrence instance might also change.
> >
> > How could one possibly correlate the specific recurrence instance
> > for which the "RECURRENCE-ID" changed?
> >
> > When the definition of the recurrence set for a calendar component
> > changes, specific recurrence instances might be added or removed
> > from the recurrence set.
> >
> > I propose to remove the text mentioned above.
>
> The jabber session participants propose that we remove this text and
> that this matter be revisited in the iTIP revision.  Are there any
> objections?

Yes, I object.  If a meeting is changed from Monday-Wednesday-Friday to
Tuesday-Thursday, and an implementation is required to preserve
recurrence-ID values, I have no idea how one would make sense of the
resulting set of events.  This is one example where the recurrence-ID not
only might change, but probably must change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070207/13253c1a/attachment.htm

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Wed Feb 7 15:49:48 2007

Am Don Feb 8 2007 schrieb Neal Gafter:
> Yes, I object.? If a meeting is changed from Monday-Wednesday-Friday to
> resulting set of events.? This is one example where the recurrence-ID not

But isn't it an entirely new event? I mean, before you reschedulled e.g. 
Wednesday's event, now you are reschedulling Thursday's event. In that case, 
I think it is conceptually cleaner to treat the event after the change one as 
a new event (with mostly the same settings as the old one, though).

So, yes, effectively you will end up with an event that has a changed 
Recurrence-ID compared to before in both viewpoints, but I would not say it's 
the same event as before. 

To make the point even clearer, let's assume you only changed the summary of 
one Wednesday's event. Now you move the whole sequence to Tue+Thu. I don't 
think that event from monday and a new, shifted event can really be said to 
be the same event, can they? (in some cases one might argue, but no in 
generality)
One open question is even, whether the change should now apply to Tue or Thu? 

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: TimHare at comcast.net (Tim Hare)
Date: Wed Feb 7 16:41:57 2007

The archives are full of long, interesting, sometimes vitriolic, discussions
of RECURRENCE-ID issues and when or where RECURRENCE-ID should or must
change. This includes appeals to the original RFC authors for clarification
of their intent. 

Before we go down that particular garden path again, I suggest that a
thorough review of the archives on that issue is in order. I will merely
point out that it really helps maintain sanity to remember that the unique
identifier of one instance of a recurrence set is composed of three values -
UID, SEQUENCE, and RECURRENCE-ID and that RECURRENCE-ID alone does not
uniquely identify the thing you're talking about.

If we were starting from scratch I believe I would be a strong advocate for
a recurrence set being separate type of component, or some sort of container
for VEVENT/VTODO/VJOURNAL components and that VRECURRENCE (to coin a name)
components would have to be added/changed/deleted in their entirety. It
would be less efficient, but I believe a lot more interoperable. 

Since we are _not_ starting from scratch, let's just make sure the rules are
simple and not open to interpretations that cause interoperability problems.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Reinhold
Kainhofer
Sent: Wednesday, February 07, 2007 6:49 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 62: RECURRENCE-ID

Am Don Feb 8 2007 schrieb Neal Gafter:
> Yes, I object.? If a meeting is changed from Monday-Wednesday-Friday 
> to Tuesday-Thursday, and an implementation is required to preserve 
> resulting set of events.? This is one example where the recurrence-ID 
> not only might change, but probably must change.

But isn't it an entirely new event? I mean, before you reschedulled e.g. 
Wednesday's event, now you are reschedulling Thursday's event. In that case,
I think it is conceptually cleaner to treat the event after the change one
as a new event (with mostly the same settings as the old one, though).

So, yes, effectively you will end up with an event that has a changed
Recurrence-ID compared to before in both viewpoints, but I would not say
it's the same event as before. 

One open question is even, whether the change should now apply to Tue or
Thu? 

Cheers,
Reinhold

- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFymVqTqjEwhXvPN0RAhEKAJ9XX4lKTsSBwkzkrD3q+y6FO5Or+gCfeffw
0i5jlZlk8GIUEcjb3W3teKY=
=iw+L
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify