Re:

Tim wrote on 08/27/2003 09:08:31 PM:
> Would someone please send me (or post) where in this discussion we've 
> 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 

> definitely says that RECURRENCE-ID changes, and the wording and order is 

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

> 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!)?

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.

> 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 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 protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...