Subject: Re: Fw: Correct handling of Recurrence-id

From: [email-masked]
Date: Wed, 2 Jul 2003 15:17:24 -0400

Doug totally missed the point on 06/12/2003 05:46:46 PM:
> You are totally hosed if you were not part of SEQUENCE:0
> or somehow loose your data.

Totally wrong!

Go reread iTIP 3.2.2 REQUEST where it clearly tells you how to distinguish 
between a NEW request and a reschedule/update. 

If the UID/RECURRENCE-ID is new to you, its a new REQUEST.  If its NOT new 
then its an update/reschedule.  Since the REQUEST is fully self contained 
it has all the CUA needs to properly instanciate it on the users calendar. 
 Done.  No "Oh, whats this?  I dont know so Ill do a 'full' REFRESH and 
wait".   No extra thrashing or having to resend data that may exactly 
match the already recieved REQUEST.

> And when 100% of the original instances change and you
> somehow missed an important change. The new instances
> will not map to the SEQUENCE:0 instances and you
> might apply them incorrectly.

If the key does not change then any missed messages are IRRELEVANT if you 
get a higher SEQUENCE (or later DTSTAMP) one than you currently have NO 
MATTER the difference in SEQUENCE or DTSTAMP.  The higher SEQUENCE simply 
means that the REQUEST obsoletes whatever you have (or missed that came 
before) and workflow is restored righ then and there.

FUD wont work here...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Jul 2003 16:54:12 -0600

[email-masked] wrote:
> Go reread iTIP 3.2.2 REQUEST where it clearly tells you how to 
> distinguish between a NEW request and a reschedule/update.  
> 
> If the UID/RECURRENCE-ID is new to you, its a new REQUEST.  If its NOT 
> new then its an update/reschedule.  Since the REQUEST is fully self 
> contained it has all the CUA needs to properly instanciate it on the 
> users calendar.  Done.  No "Oh, whats this?  I dont know so Ill do a 
> 'full' REFRESH and wait".   No extra thrashing or having to resend data 
> that may exactly match the already recieved REQUEST.

If I get an object that looks exactly the same as an
update to an instance, I am going to do a REFRESH
to make sure that I did not miss the original full REQUEST.
They look *exactly* the same. Don't do it that way. Send
the ATTENDEE a REQUEST (minus RECURRENCE-ID) on their
first invite custom tailored to what they will be attending
(What is what I expect to get back from the REFRESH anyway).

ITIP shows that (REQUEST with RECURRENCE-ID) as an example of how
to update an instance, not how to originally invite an  ATTENDEE.
I think it is reasonable to assume that implementation will use
that method as the way to update an instance and use the documented
ways to originally invite a new ATTENDEE.

--

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

                 We Do Standards - You Need Standards