[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