Subject: Re: Component tombstones. Your feedback needed.

From: Ian Woollard <[email-masked]>
Date: Mon, 21 Jun 1999 21:33:45 +0100

There's something about timestones I don't like; but I don't
know what it is. Its probably just me ;-)

One question though: do you really want all your timestones
getting deleted if someone typed in the wrong year whist
setting the real time clock?

Wouldn't that cause horribly subtle problems?

I think that using SEQUENCE counts for pruning things is
much better: 

>  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.

If you include a version number for each change to the meeting,
the fact that the SEQUENCE number is nonconsecutive- that
would indicate a lost message. (You might get the message eventually-
but how long are you going to wait for that eventuality- that's
clearly dependent on the CUA.

In any case, resynchronise the database and the problem
goes away, the fact that the event is no longer in the
database indicates that the event is deleted.

-- 
-Ian        ([email-masked])

2 Secrets to success: 1. Don't tell everyone what you know.

---

From: John Stracke <[email-masked]>
Date: Mon, 21 Jun 1999 21:34:41 +0000

> Wouldn't that cause horribly subtle problems?

Not too subtle--just people possibly getting old components back.
Annoying, but at least you don't lose any real data.  (And it can be made
extra unlikely by using NTP instead of hand-setting your clocks.)

Besides, the expiration isn't really part of the protocol.  The protocol
need only specify that the tombstones have to be kept for some safe length
of time; what happens after that is implementation-specific.  It could be
that expired tombstones get moved into a trashcan, and don't actually get
deleted until after daily backups.  Or it could be that they're kept
forever; it's just a matter of disk space (and maybe risk--lawyers could
subpoena calendar data just like they do email).

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

---

From: [email-masked] (Steve Mansour)
Date: Mon, 21 Jun 1999 17:01:19 -0700

> know what it is. Its probably just me ;-)

no. they're just ugly.

> setting the real time clock?

that could definitely be a problem, for more than just tombstoned calendar
components :-)

> I think that using SEQUENCE counts for pruning things is

Which is why we have to keep tombstoned events... If you actually delete the
event, you don't have a SEQUENCE number to use as a basis for comparison.

The question is how long do you need to keep them around?

> would indicate a lost message.

how would you know that the numbers were out of sequence if you really
deleted the event when it was canceled?

> (You might get the message eventually-

yep. that's the issue

> goes away,

???  I don't follow.  There is no resynchronization in the example above.
The problem exists if you don't keep the tombstone in your calendar.  If you
had deleted the event when the CANCEL came, then the SEQUENCE 1 message
arrives, how would the CUA know that there was a CANCEL with SEQUENCE 2 ??
It was deleted.

> the fact that the event is no longer in the

No!  There are many things that could have happened.

   * It could easily have been that SEQUENCE 0 was lost and SEQUENCE 1 was
     the first one to arrive. In this case you need to save SEQUENCE 1 even
     though you don't have sequence 0
   * Another way this could happen is if an attendee was added in SEQUENCE
     1. The new attendee will never get a SEQUENCE 0 version of the event.
     The first SEQUENCE number the new attendee sees is that of the version
     in which they were added to the attendee list.

The point is that either of these situations look exactly like if the cancel
was processed and the event was deleted from the database.

You need a tombstone to detect the difference.

-Steve