Subject: Re: Component tombstones. Your feedback needed.

From: Frank_Dawson/CAM/[email-masked]
Date: Mon, 21 Jun 1999 17:11:38 -0400

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

>Why is that?

John:

This gets back to the difference between "calendaring" and "scheduling". The
former is direct calendar manipulation. For example, when you DELETE an entry,
it is gone from your calendar. The latter is a workflow of operations that are
"requested" to be performed on a calendar.

In a simple analogy, when your mum tells to you come it is quite different than
when a friend sends you an invitation to a birthday party ;-)

I think that Andre Courtemanche corrected Steve's append with the clarification
that "tombstones" relate to a discussion we had about the result of the DELETE
calendaring command, not the CANCEL scheduling command.

Normally, the result of a DELETE operation is that the event is actually removed
from your calendar store. The CANCEL operation results in the event being marked
with a status of CANCELLED. It may or may not be removed from your calendar
store.

In any case, if the deleted entry is subsequently referenced by a CAP scheduling
command, such as REFRESH or even a COUNTER, whose delivery has been
inadvertently delayed for some time after the event was deleted, then you need
to be able to detect not that the UID in the refresh references a non-existent
entry, but that it references an entry that nolonger exists, because it has been
deleted.

I believe that the Montreal discussion came up as we worked through scenarios
that involved the possibility of a calendar being manipulated by a combination
of CAP calendaring commands (e.g., CREATE, READ, DELETE, MODIFY) and CAP
scheduling commands (e.g., REQUEST, REPLY, CANCEL, REFRESH, COUNTER,
DECLINECOUNTER, etc.).

-- Frank

---

From: [email-masked]
Date: Mon, 21 Jun 1999 20:29:52 -0400

Steve

That is correct.  My assumption was that there was not
semantic mapping between the iTIP CANCEL and the 
"Marking a component with a tombstone for it to be deleted". 
What Alex T. was making suggesting, I think, was that there 
should be some "STATUS" pre-processing when an event was
"Marked with a tombstone"

Another argument to disassociate CANCEL status from tombstone
is that, in my opinion, all calendar components 
need to be "Marked for deletion", not only VEVENTS.
Only VEVENTS have the STATUS property.

My comments was that once a component has been marked for
deletion, then you can't go back. 

I agree with you that if a VEVENT is CANCELED, then you
can certainly revert to the previous without problems

Andre Courtemanche
CS&T

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 21, 1999 8:14 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Component tombstones. Your feedback needed.

hmmm... iTIP made no statement about what happens to the UID of an event
after it is cancelled. That is, there's nothing in iTIP that prohibits
the following:

     Suppose I create an event and invite a bunch of attendees with
     iMIP request (UID:123, SEQUENCE:0). Then later, I cancel event
     with uid 123,  I send around a bunch of iTIP cancel messages
     to the attendees (UID:123, SEQUENCE:1). Then a little later I
     decide the meeting is back on, so I send out a request to all
     the attendees (UID:123, SEQUENCE:2).

Does this seem OK?  It seems like it should work.

-Steve

[email-masked] wrote:

> Well, that also brings up the point: Should
> components could be reanimated by changing
> the status by removing the tombstone ?
>
> My opinion is, no, under no circumstances should
> a component be "reanimated", by removing the
> tombstone, although it is real tempting to use
> it for "Undelete" capability.
>
> Why ?
>
> Complexities are far reaching.
>
> Andre
>
> -----Original Message-----
> From: Alexander Taler [mailto:[email-masked]]
> Sent: Monday, June 21, 1999 5:20 PM
> To: [email-masked]
> Subject: Re: Component tombstones. Your feedback needed.
>
> It also seems that the tombstone property would have to be
> distinct from the "STATUS" property, since you want to
> know that the tombstoned meeting was cancelled, in case
> someone tries to reanimate it.
>
> Alex

---

From: Frank_Dawson/CAM/[email-masked]
Date: Mon, 21 Jun 1999 21:44:03 -0400

Andre:

We discussed this for some time during the iCalendar/iTIP development. It was in
terms of how easy it would be for the Organizer to "breath life" into a
CANCELLED event or to-do by just reissuing a REQUEST for the UID associated with
the calendar component. You may notice that all that is required is to re-issue
a REQUEST with an incremented SEQUENCE number. A CANCEL will increment the
SEQUENCE number. By awaking the event or to-do, you just increment it one mo'
time. We called these "zombie" events. As they would be like "walking dead"
events or to-dos. It was decided that what you did with "awaking the dead" was
beyond the scope of current RFCs. Bruce Kahn had some involvement on this, so
maybe he wants to pipe-in.

But, I agree with you that providing support for awaking up CANCELled or DELETEd
events is beyond what we should be trying to complete by JULY.

-- Frank

---

From: Frank_Dawson/CAM/[email-masked]
Date: Mon, 21 Jun 1999 22:01:44 -0400

>Any suggestions on where to capture the "tombstone" information?  A new
property?

Well, remember that a tombstoned calendar component is not a nominal one. It
could have all of the data removed except for minimal "tombstone" info. So,
maybe it should have it's own restriction form, based on the component type
(i.e., VEVENT, VTODO, VJOURNAL). In this case, it would have a METHOD of
DELETED, as only the DELETE operation would create the tombstone, not the
CANCEL.

-- Frank

---

From: Frank_Dawson/CAM/[email-masked]
Date: Mon, 21 Jun 1999 21:50:04 -0400

>    the attendees (UID:123, SEQUENCE:2).

The chronology of discussion is right on with my memory. The example is also
correct!

---

From: Frank_Dawson/CAM/[email-masked]
Date: Mon, 21 Jun 1999 22:00:36 -0400

Actually, both VEVENTs and VTODOs and VJOURNALs have the STATUS component
property.

---

From: [email-masked]
Date: Mon, 21 Jun 1999 21:57:07 -0400

Is the property defined to be able to have
the "CANCEL" value ?

-----Original Message-----
From: Frank_Dawson/CAM/[email-masked]
[mailto:Frank_Dawson/CAM/[email-masked]]
Sent: Monday, June 21, 1999 10:00 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Component tombstones. Your feedback needed.

---

From: Frank_Dawson/CAM/[email-masked]
Date: Tue, 22 Jun 1999 04:57:16 -0400

>Is the property defined to be able to have

Refer to section 4.8.1.11 of RFC 2445. Yes, it takes the "CANCELLED" enumerated
value.

- - Frank

---

From: Doug Royer <[email-masked]>
Date: Tue, 22 Jun 1999 07:56:05 -0700 (PDT)

> Date: Mon, 21 Jun 1999 22:01:44 -0400
> 

You just read my mind. From the schema discussions we had
in Montreal (I am sure Pat will be sending the notes soon),
I think this is exactly where it should go.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Tue, 22 Jun 1999 07:50:52 -0700 (PDT)

> Date: Mon, 21 Jun 1999 17:13:45 -0700
> From: [email-masked] (Steve Mansour)
> 

If I as the ORIGINATOR iIMIP a CANCEL.  Who deletes it from the CS?
It looks to me as if the destination CUA must at some time delete it
from the store.  Then if the ORIGINATOR decides the meeting is back
on, and sends out a request to all the attendees (UID:123, SEQUENCE:2)
Then you are close to the problem that Andre is talking about.

So how can we keep it from being an un-delete?  I don't really
understand why un-deleting it would be a problem.

-Doug