What if the first meesage is an ADD?

I've retitled the thread since we are no clearly on a different topic.


> Method B did NOT send a sequence starting at ZERO to attendee-2.
> Attendee-2 was not invited until sequence:2. So no such history exists
> in attende-2's CS. The ONLY way that attendee-2 can expand
> the instances for the object it was invited to is from the object
> it self.

My apologies.  The example was hard for me to follow.  I obviously did
not understand that Attendee-2 did not receive all the messages.  In the
future, if you could clear up such misunderstandings in your first reponse
it would be appreciated and cut down on the bandwidth.  Thank you.


In terms of constructing the set of RECURRENCE-IDs, enumerating the set
described by an ADD or REQUEST with a UID only message is absolute in
terms of defining the valid RECURRENCE-IDs.


So reconstructing Attendee-2's CS if it did not receive messages a or b
(SEQ:0 and 1 respectively) the CUA will look in its store for UID:XXX and
not find it.

The results are undefined.

However, consistent with iTIP's mandate to handle lost and missequenced
messages it should treat the ADD like a REQUEST and then since it obviously
is missing data (as evidneced by both a SEQ:2 and that it has just received
an ADD for a non-existant event (i.e. way out of context for the UID)) it
sends a REFRESH request to the ORGANIZER.

This results in the "2-dec-2003 at 3:30" instance being put on the calendar
immediately and requesting the missing info.  THe CS ends up with exactly
2 objects:
1) UID:XXX/SEQ:2 - a set describing an event 2-dec-2003 at 3:30
2) UID:XXX/RECURRENCE-ID:2-dec-2003 at 3:30/SEQ:2 - the instance in
question.

The RECURRENCE-ID is "at 3:30", not because it doesn't have prior info and
had to take it from the instance object, but because taking it from the
DTSTART
is the right thing to do.  An ADD is a set defining moment.  Even if it had
the prior info it would still do exactly the same thing.  It's not forced to
use DTSTART because of lack of info.  It does so because that's what the
standard says to do.

An ADD will increase the number of instances present in a recurring
event.  It figures out the _newly created_ RIDs by expanding the set
described by the ADD message and merging that set with the prior
definition.

The RID calculation is no different than using the DTSTART value to figure
out what the RECURRENCE-IDs are for a new REQUEST.  These messages
are the first time these instance have ever come into existence and
therefore use the initial DTSTART as the RECURRENCE-ID.  However, once
defined, they persist from that point forward until the RID is no longer
part of the set described by the rules of UID only object.


> I can ftp or webdav fetch a sequence:2 .ics file, or get an imip
> sequence:2 method:request object all by itself.

But the example didn't use a method:request object, it used a method:add.
If it had used sequence:2 method:request object then it would have
redefined the whole series to be a singleton.  1-dec-2003 and 3-dec-2003
would have been erased.  There would have been no need to send a REFRESH
because it clearly has the most recent information.

> So, it can not be
> true that the expansion of the sequence:2 object depends on
> recurrence-id's that pre date the sequence:2 object because
> attendee-2 will not have that history.

The expansion of the sequence 2 object itself doesn't depend on prior
data, but the very nature of the "add" message certainly does.  An
ADD unlike a REQUEST is not an authoritative description of the entire
event.  It is an addendum to the existing data.  Therefore, by definition
an ADD depends on prior data.  If that data is absent the CUA should send
for a REFRESH.




So what's the question?

-- Michael --