Subject: Re:

From: Tim Hare <[email-masked]>
Date: Wed, 27 Aug 2003 21:08:31 -0400

Would someone please send me (or post) where in this discussion we've 
discussed the following paragraph from 3.7.1 in iTIP? As I read this 
paragraph, this says that RECURRENCE-ID changes when some substantive 
change to the entire VEVENT changes, certainly, but the last sentence 
definitely says that RECURRENCE-ID changes, and the wording and order is 
such that it implies that this happens for an instance change.

------------------------------------------------ BEGIN  BLOCK QUOTE 
--------------------------------------------------------------
    An instance of a recurring event is assigned a unique identification,
    "RECURRENCE-ID" property, when that instance is renegotiated.
    Negotiation may be necessary when a substantive change to the event
    or to-do has be made (such as changing the start time, end time, due
    date or location). The "Organizer" can identify a specific recurrence
    instance using the "RECURRENCE-ID" property. The property value is
    equal to the date/time of the instance. If the "Organizer" wishes to
    change the "DTSTART", the original "DTSTART" value is used for
    "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
    reflect the change.  Note that after the change has occurred, the
    "RECURRENCE-ID" has changed to the new "DTSTART" value.
------------------------- END BLOCK QUOTE --------------------------------

I also would like to know, if the RECURRENCE-ID _is_ fixed, then why wasn't 
an arbitrary sequence number used for RECURRENCE-ID rather than the 
date-oriented one (in my view the enumeration method of identifying 
recurrence instances would have eliminated a lot of semantic confusion in 
our discussions!)?

The one answer I come up with is "So Calendar Stores which don't 
automatically expand recurrence sets can easily determine the RECURRENCE-ID 
of one instance". If that is so, then at the moment when one instance is 
changed, it must be stored in the CS as though it were a complete VEVENT, 
correct? If the CS doesn't want to store that one instance, then it must 
modify the VEVENT to have recurrence rules that reflect the original set 
PLUS the change - which is a modification to the pattern, and thus 
_requires_ SEQUENCE to be updated. I'm not completely convinced that 
SEQUENCE is has to be updated for _all_ changes to individual instances, 
because that would require every instance to be stored as a VEVENT 
(SEQUENCE being a property of VEVENT as near as I can tell from RFC2445. If 
SEQUENCE is a property of each instance, then every instance must be 
expanded whenever it is updated, which in a sense "promotes" it from one 
instance of a recurrence set to a VEVENT in its own right.

Notice, I'm not arguing right or wrong here, I'm trying to understand what 
iCal says about these as objects versus what the communication protocols 
say about it.

I still think we need to come up with one set of objects and users so we 
can all talk about the same items with the same identifiers. At a minimum, 
this should include one VEVENT that doesn't have recurrence rules, one set 
that does, and ORGANIZER, some ATTENDEEs, some official delegates, AND some 
users that get forwarded the information unofficially. We can then also 
define a set of actions to be performed on these objects. If we can do 
this, then we can all discuss things from the "same page".  I will try to 
work this up over the next couple of days and then find a place to post it. 
Maybe it will help, maybe not, but I believe it's worth a shot.

Tim Hare

---

From: [email-masked]
Date: Thu, 28 Aug 2003 17:49:17 -0400

Tim wrote on 08/27/2003 09:08:31 PM:
> discussed the following paragraph from 3.7.1 in iTIP? 

I believe that Satya recently posted a summary of that thread already. You 
can also check the official archives and search for the subject "
Recurrence ID changes?" dated 07/21/99 01:26:47 PM by Dan Hickman.

As has been previously noted and confirmed by the recent posting by 
Derik/Frank there are some known errors in iTIP and thats one of them. 

>                                                    but the last sentence 

> such that it implies that this happens for an instance change.

This last sentence is the only text in iCalendar or iTIP that says 
RECURRENCE-ID changes.  Its contrary to the text immediately above it, to 
the text in iCalendar and to all the logic in elsewhere in iTIP describing 
workflow sequencing and recovery.

It should be noted that iTIPs role is not to define (or redefine in this 
case) the behaviour of iCalendar properties; its job is to provide 
semantics to the properties.  iCalendar is the RFC that defines properties 
and their behaviour so it should be considered the definitive source for 
RECURRENCE-ID and its behaviour.

> recurrence instances would have eliminated a lot of semantic confusion 
in 

We chose to use a date/time value for the RECURRENCE-ID instead of a 
different enmerated data type like an integer or something else because:

A) we already had a frame of reference when discussing instances and that 
was the date/time of the instance ("The second Monday instance got moved 
to the next Tuesday at 3PM", etc) 
B) it seemed the most logical data type to choose because its a useful 
part of the instance that can be reused (ie: When you create the instances 
in the set, you can calculate the RECURRENCE-ID value w/o the Organzier 
having to send them all plus you can use that when putting the entries on 
the calendar) and 
C) since we had the ability to have infinite repeating set (joy oh joy!) 
there was NO way for both the Organzier to send the RECURRENCE-ID values; 
each recipient had to be able to correctly generate them to match the same 
values the Organzier has/uses.

The reason we opt'd for a fixed design was because of sequencing issue and 
the poor performance of iTIP in those situations.  Its all in the side by 
side analysis I posted a couple weeks ago in response to your first 
posting.

> say about it.

I did not see any followup from Tim regaring my analysis of both the delta 
and fixed RECURRENCE-ID models nor do I see any in the archive.  I am 
interested to know if you saw them and any response or thoughts you have 
in response to it.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 28 Aug 2003 16:40:37 -0600

[email-masked] wrote:
> I believe that Satya recently posted a summary of that thread already. 
>  You can also check the official archives and search for the subject 
> "Recurrence ID changes?" dated 07/21/99 01:26:47 PM by Dan Hickman.
> 
> RECURRENCE-ID changes.  Its contrary to the text immediately above it, 
> to the text in iCalendar and to all the logic in elsewhere in iTIP 
> describing workflow sequencing and recovery.

So do you also claim that Derik's and Frank's recient post also
is in error when it says they change? Where they in error again?

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards