Component tombstones. Your feedback needed.

[sman@xxxxxxxxxxxx (Steve Mansour)]

Hey all,

Something came up at the Montreal meeting regarding tombstones. A lot of
people weren't familiar with them. We also realized that there is no
explicit mechanism in iCalendar to flag a component such as an event,
to-do, or journal as a tombstone. And finally, there is a usage issue
with tombstones. So, we felt like it was time to notify the list and see
what you all think.

What are tombstones? They are "deleted" events, to-dos, and journals
that remain in a calendar store simply to indicate that the component
has been deleted or canceled. Why not just delete them from the
database?  There may be many reasons for particular implementations to
keep them, but there is definitely an iTIP-related reason for keeping
them. Consider the scenario where I:

  1. send out an iMIP REQUEST to an event, which is accepted by all
     attendees,
  2. send out another iMIP REQUEST with a change for the meeting time,
  3. and finally send out an iMIP CANCEL of that meeting.

Suppose that the second request was somehow delayed or lost in e-mail
such that the iMIP CANCEL message was received by an attendee *before*
the second iMIP REQUEST. If the attendee completely removes the meeting
from their calendar as a result of receiving the CANCEL, and the second
iMIP request eventually arrives, the attendee may end up putting a
cancelled meeting on their calendar.

The most common solution to this situation is to keep a "tombstone"
version of the event which marks it as deleted. Recall that the SEQUENCE
number of an iTIP message is incremented as substantive changes are made
to the event (or todo or journal). So in the scenario above, the first
request had sequence 0, the second request had sequence 1, and the
cancel had sequence 2. When the attendee receives the belated second
request, its sequence number (1) is compared to that of the tombstoned
event (2).  Since the sequence number of what is in the calendar store
is greater than that of the request just received, the request can be
ignored.

What are the issues?

First, how is an event marked as a tombstone? Is it enough to say that
an event with a STATUS property of CANCELLED indicates that it is a
tombstone? Do we need a separate TOMBSTONE value for STATUS?

Second, how long do we need to keep tombstoned components in a calendar
store?  A week after the dtstart of the component? A week? a month? 3
months?

We need your feedback on this.

-Steve
begin:vcard 
adr;dom:;;;Mountain View;CA;94043;
n:Mansour;Steve
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, and Executioner
tel;fax:650-937-2103
tel;work:650-937-2378
x-mozilla-cpt:;0
fn:Steve Mansour
end:vcard