Re: request + add

I need to apologize for getting the original examples wrong again.

All of Doug's examples moved the 2nd instance from noon to 2pm
not noon to 3:30.  To remain consistent with the previous posts
I made I am going to continue using 3:30 as the start time for the
added instance.  It will still be 1.5 hours long, making the new
time be from 3:30pm-5pm (instead of being from 2pm-3:30pm).  I'm
sorry for not reading it right to begin with.


"Mark Smith" <[email protected]> wrote in message
news:[email protected]...
>
> Michael Fair wrote:
>
> >
> > 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.
>
> Okay, now what if it gets the sequence:1 request and the sequence:2 'add'
> as shown in 'B'.  As all three instances can not be represented in
> one 'method request' object because the duration of all three instances
> are not the same. Now the master object is at sequence:2, as is
> attendee-2.

This can actually be described in one method:request object as I'll
demonstrate below in response to a REFRESH request.  You are right
if what you meant was that it can't be described in 1 VEVENT component.


> The recurrence-id's can be calculated from what attendee-2 has. Correct?
> And it will be the same recurrence-id's as organizer. Correct?

This sounds correct, but since we haven't rescheduled any of the instances
yet it's not all that meaningful...  I'm also not sure if you're playing
with the ordering of the messages so I'll address both orderings.  I
apologize if I'm overcomplicating your assertions, but the terse style
and my past mistakes at misunderstanding your questions makes me doubt
that I understand everything you're asking.


Both scenarios will end up with matching RIDs (matching between ORG and A2).
I just want to be sure we're clear about how/why.

I also think a more meaningful example would be to use something that
actually uses an instance reschedule in the mix since that's when DTSTART
and RECURRENCE-ID are no longer in sync, but I'm following your lead at
the moment (for instance, request - instance reschedule - add).

Scenario 1:
If A2 receives S1(request) then S2(add) then the CUA will not send a
REFRESH.

Upon receipt of S1 the CUA will store 1-Dec and 3-Dec instances along with
the
UID:XXX object in the CS all at SEQ:1.

At this point the RIDs for UID:XXX on both ends will be:
1-Dec-2003 at noon
3-Dec-2003 at noon

Then upon receipt of S2 it will store the data for instace 2-Dec, merge the
DTSTART,
RRULE/RDATE and EXRULE/EXDATE values from S2 (if there are any) with the
ones
from S1 and update the UID:XXX object with the new info.  It also update the
UID:XXX
object and the instances 1-Dec and 3-Dec to be at SEQ:2.

The RIDs for UID:XXX on both ends are now:
1-Dec-2003 at noon
3-Dec-2003 at noon
2-Dec-2003 at 3:30




If A2 receives S2 (add) then S1 (request) then the CUA will send a REFRESH.

After the receipt of S2 the RIDS in the CS for UID:XXX are:
2-Dec-2003 at 3:30

It will ignore S1 and not be synchronized until the REFRESH response
arrives.

The ORGANIZER will send the following message in response to the REFRESH:
BEGIN:VCALENDAR
  METHOD:REQUEST

  BEGIN:VEVENT
   UID:XXX
   SEQUENCE:2
   ...
   DTSTART: 1-dec-2003 at noon
   DTEND: 1-dec-2003 at 1pm
   ...
   RDATE:3-dec-2003 at noon
   RDATE:2-dec-2003 at 3:30
  END:VEVENT

  BEGIN:VEVENT
   UID:XXX
   RECURRENCE-ID:2-dec-2003 at 3:30
   SEQUENCE:2
   ...
   DTSTART: 2-dec-2003 at 3:30
   DTEND: 2-dec-2003 at 5pm
   ...
  END:VEVENT

END:VCALENDAR

(As an aside, had the ORGANIZER done a normal reschedule, then the RDATE
 and RECURRENCE-ID values would be "at noon" and the SEQUENCE would most
 likely be 1.  Other then that, the response would be the same.)

After receipt of the REFRESH response the two CS' would be in sync.

-- Michael --

PS I am concerned that at some point in this thread you might try and bring
A1 who received the proper instance reschedule message back into this and
say
the RIDs don't match.  However, that can't legally happen because it would
violate the uniqueness of UID:XXX and is an entirely different conversation.