Re: How to handle out-of-sequence ADDs.

Shriram V wrote:

> Hi all,
>  
>  
> I want to know how out of sequence ADD messages is handled.
>  
> Suppose that a user has an event with SEQ #1 in his store.
> Now if ADD with SEQ#3 comes up, what should be done?
> Since the received SEQ# > current SEQ#, this is a more recent ADD.

> At this point if I accept ADD#3 as update, the SEQ# of the event in my 
> calendar would increase to #3.
> Next when older ADD#2 (or any other method) arrives, it will be 
> rejected, since SEQ# < current SEQ#.

> In effect, user's version of vevent, although indicates the most 
> recent SEQ#, is not up-to-date.
> How does iTIP handle this? Or am I missing something?

Per iTIP:

REFRESH A request is sent to an "Organizer" by an
                   "Attendee" asking for the latest version of an
                   event to be resent to the requester.

and:

   The "UID" must be that of the existing event. If the "UID" property
   value in the "ADD" is not found on the recipient's calendar, then the
   recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
   updated with the latest version of the "VEVENT".  If an "Attendee"
   implementation does not support the "ADD" method it should respond
   with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".


In effect the recipient does not have the current UID object, so send a 
REFRESH
to get the latest copy. What is received should be #3 or bigger.

-- 

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

               We Do Standards - You Need Standards