Re: ADD does not INVALIDATE current PATTERN

I totally agree that an ADD does not invalidate any preexisting
RECCURENCE-ID.

I completely disagree that ADD does not change the current pattern.

ADD does change it only in a non-destructive manner though.

If I have an every Monday event and then ADD every Tuesday,
I have a new set.

This new set is every Monday and Tuesday.

I communicate this by telling existing ATTENDEEs to ADD every Tuesday.

If I invited a new CU post-ADD they would recveive a single UID
with recurrence rules describing every Monday and Tuesday.

The SEQUENCE value for the base event has increased.  The UID/SEQ
pair value has therefore changed and if ADD could ever be a
destructive change to the pattern then it could invalidate RIDs
according to the rules.

If we said that ADD did not change the recurrence pattern then it
would be impossible for ATTENDEEs to verify the set of possible
RECURRENCE-IDs through the response to a REFRESH.

If it didn't alter the recurrence rules, then the response object
would only contain the description of "every Monday". The "every
Tuesday" that had been added would be removed from the Calendar.

Since ADD can never be a destructive act it is only necessary to
send a description for the new set of instances.  The rules
described in the "ADD" message can be safely merged with the
existing rules of the base object while increasing the
SEQUENCE number.

This process is shown in example 4.4.7 of iTIP.
However where I expected the fourth "RDATE" to be in the REFRESH
response object was an "Error! Bookmark not defined" statement.
However looking closely, you can see that the "4th instance" is
indeed listed there.


Example 4.4.7 also covers "ADD".
This one however reveals a really strange case for preexisting
modifications to instances prior to the ADD.  In the example,
the new SEQUENCE update is going to be 7 and therefore by
design all the existing instance modifications will be <7.

The ADD is going to set the base object to be SEQ:7 which would
trump all instance specific data and force them to be removed
from the calendar.

However, from the text and examples, while it doesn't explicitly
address it, there is an implication that using an ADD will
preserve all existing instance specific modifications.

So is the right move to implicitly update all instances with
updates to 7+1 so that the instance data gets preserved?

The main problem I'm thinking of is CUs are going to want to
update their status info for those instances.  Their responses
should be at least SEQ:7, but preferably SEQ:>7.  Otherwise,
even though nothing about those instance has changed, the
ORGANIZER's CUA will think that it has not seen a response
for the latest version of those instances yet.

Or am I missing something simple?

-- Michael --

<[email protected]> wrote in message
news:OFE7C28BE3.25A92664-ON85256D91.006CD53E-85256D91.006CC38F@notesdev.ibm.com...
> An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus it does
> not change the pattern of existing set.
> If an ADD INVALIDATED the existing set, than you would be forced to send a
> new RRULE/RDATES/EXRULE/EXDATES with ADD.
> In that case the ADD would be pointless, just include the new DATE in the
> new rules.
>
> An ADD is equivalent to sending the invitee an REQUEST with a
> RECURRENCE-ID that he does not currently have.
> The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his
> calendar, storing off RECURRENCE-ID that CHAIR supplied.
>
> The CHAIR does not really care either.  He is in control and just adds it
> to his set.