Subject: RE: Component tombstones. Your feedback needed.

From: [email-masked]
Date: Mon, 21 Jun 1999 12:44:42 -0400

Steve,

This is a very important issue for mobile devices. My
feeling is it should be in the first version of the
draft.

Why ?

There are many cases that needs this but just consider
mobile devices.  Given a mobile device that holds a 
copy of the calendar components of a store, upon 
syncronization with the "Master" store, if it 
has an entry that doesn't exist on the "Master" 
non-mobile store, then there are 2 conclusions the 
mobile  device can come up with:

1. The mobile entry is a new one that has to be added on
the "Master" non-mobile.
2. The mobile entry is an entry that has been
deleted.

The tombstone allows you to make the correct choice.

My opinion about using CANCEL property:

1- CANCEL is part of the information of the event and
can't be used as tombstone information. There is a
world of difference between a canceled meeting and
a meeting that has been deleted.

PROPOSITION for the "Expiry of information"

2- In my opinion, DELETION (or purge ) of the components 
that have been marked for deletion should be an attribute 
of the calendar itself. If the attribute is not present on
the calendar then tombstone entries are not retained.

Why a property on the calendar ?  

The retention of a calendar entries that have been
marked for deletion will greatly be based on the
use of the calendar itself.

For people that don't agree that tombstones are 
not important, I could come up with other cases just 
like this one that makes tombstones very valueable.

Andre Courtemanche
CS&T

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 21, 1999 11:50 AM
To: CalSched working group
Subject: Component tombstones. Your feedback needed.

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:32:53 +0000

> a meeting that has been deleted.

Why is that?

> the calendar then tombstone entries are not retained.

I disagree--sort of.  I believe tombstone entries are necessary whenever
you've got time lags going on, for the reasons Steve laid out in the
original message.  On the other hand, it is certainly the case that some
users will need them to last longer than others, so it is reasonable for
tombstone lifespan to be configurable on a per-calendar basis; but there
should be some lower bound (probably one recommended by the vendor and set
by the admin).

--
/=============================================================\
|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 |
\=============================================================/