Subject: Component tombstones. Your feedback needed.

From: [email-masked] (Steve Mansour)
Date: Mon, 21 Jun 1999 08:49:33 -0700

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

---

From: John Stracke <[email-masked]>
Date: Mon, 21 Jun 1999 17:25:59 +0000

> tombstone? Do we need a separate TOMBSTONE value for STATUS?

I wouldn't think so--if it's there, and CANCELLED, then it's a tombstone.
Right?

> store?  A week after the dtstart of the component? A week? a month? 3

TCP's answer in the analogous case (TIME_WAIT) is "twice the maximum
segment lifetime" (where "segment" basically means "packet"--or, in our
case, one iTIP message).  The MSL is basically an estimate of the diameter
of the network in seconds; in the case of email, this diameter may reach
days, but rarely more than a week.  If we let the MSL be two weeks as a
conservative estimate, then tombstones should probably last a month.

However, it's important to note that this depends strongly on the network
in use.  For components that are strictly on the corporate intranet
(assuming your intranet has good email service), you could cut the
tombstone lifetime to a week (and even that would be overkill, mostly just
in case you get an email outage over a long weekend or something).  For
implementations where the iMIP stack doesn't check email unless the user
pushes a button (as opposed to, say, a CS that polls your IMAP mailbox
continuously), it might be necessary to bump up the tombstone lifespan to
be greater than the maximum reasonable time someone could be on
vacation/sabbatical.  (An implementation might make it possible to increase
the lifespan just for individual users who actually are on vacation.)

So we should probably not prescribe a fixed time in the protocol; instead,
we should recommend something and give rules of thumb for how to figure the
tradeoffs.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/