[Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE

Bruce Kahn Bruce_Kahn at notesdev.ibm.com
Fri Sep 28 14:20:17 PDT 2007


Eliot Lear <lear at cisco.com> wrote on 09/13/2007 10:19:02 AM:

> SEQUENCE is used as a synchronization aid and as a change indicator.
> 
> However as a synchronization aid we already have DTSTAMP.

I'm playing catch up on this thread but I wanted to point out bits that 
may have been overlooked from what I can see.

DTSTAMP is defined as "The property indicates the date/time that the 
instance of the iCalendar object was created" and the descriptive text 
clarifies how it is different than the other timestamps like 
LAST-MODIFIED.  It is the date/time that the iCalendar object was created 
so its the date/time of when you created the Invite, Reply, etc. 

You can never safely assume that all clocks in the world will be in sync. 
So even if you were to try and use a timestamp to track sequencing of 
messages, it is not always reliably done.  Consider the simple case of a 
secretary with a different client machine (and thus different clock) or a 
user uses different computers (eg: Internet cafes/kiosks).   Since 
date/times can vary between 2 system, how can the Chair accurately tell if 
the ACCEPT was done before or after the DECLINE if it is possible that one 
clock is, say, 10 minutes behind the other?  Despite changing my 
participation status only 5 minutes later, it could appear as if I did the 
actions in reverse order than I actually did.

As Tim noted there was lots of talk over this in the original effort so 
see the archives for more info/background.

> At the very least if we choose not to do that, we should be much more 
explicit 
> about when SEQUENCE is supposed to change (e.g. ORGANIZER MUST change 
SEQUENCE 
> for these things (...) and SHOULD change SEQUENCE for these things (...) 
under 
> certain circumstances.

The text under SEQUENCE (Section 4.8.7.4 Sequence Number) has a pretty 
decent description of when to update SEQUENCE already.  In a nutshell, if 
the change affects the set of instances or the date/time of an entry then 
SEQUENCE must change. so that all responses to the "old" versions can be 
detected and properly ignored.  Changes that do not affect the date/time 
or instance set such as typo corrections or agenda changes do not require 
a change but they can (at the users discretion). 

What changes to the list do you think are in order?

Bruce
===========================================================================
Bruce Kahn                                INet: 
Bruce_Kahn at notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070928/571b01c6/attachment.htm


More information about the Ietf-calsify mailing list