Subject: Re: CMD;opt=markfor:DELETE [Was: discussion METHOD]

From: "John Stracke" <[email-masked]>
Date: Fri, 24 May 2002 16:05:12 -0400

>The only reason that the DELETE state exists is so that
>the 2nd and up synchronization processes can tell if something
>has already been done.

Hmm.  But then how does any CUA know when it's safe to delete the 
component for real? Is a CS going to be leaking disk space over time, 
unable ever to delete anything?

Perhaps a component in DELETE state should have no properties other than 
its UID?

/=================================================================\
|John Stracke                    |Principal Engineer              |
[email-masked]   |Incentive Systems, Inc.         |
|http://www.incentivesystems.com |My opinions are my own.         |
|=================================================================|
|Whose cruel idea was it for the word "lisp" to have an "S" in it?|
\=================================================================/

---

From: Doug Royer <[email-masked]>
Date: Fri, 24 May 2002 15:11:42 -0600

> unable ever to delete anything?

Yes that is an issue. The problem is that the CS will never
know how many CUAs need to synchronize, and over what period
of time.

Only the CUA or CU will ever know. We just need to provide
a way for the CUA to remove the object, and a way for the CUA
to specify that an object is marked for removal. We do not need to
specify when the physical removal is done. When to remove
the object is a policy decision and not a protocol issue.

> Perhaps a component in DELETE state should have no properties other than

No - duplication of objects; If you get invited twice (once
on the xx-group mailing list and another on the yy-group mailing list.)
You need to know that a METHOD:REQUEST was deleted with the same
contents, so the 2nd -> up CUA will not ask the CU again when
they see the 2nd copy of the same vevent - when they had already
replied "NO". So you would need to not only know the UID, but the
METHOD and the contents. Perhaps some of the contents could be removed,
but I don't think we need to decide that until any synchronization
draft. So this is another CUA <-> CS synchronization issue.

We deferred the synchronization solution for another draft.
And only required that CAP allow for synchronization. We had
discussed and concluded it only meant marking an object for deletion
and the ability to upload/download new or changed VAGENDA contents.

The only unanswered questions on this issue are:

  o How do you know that an object is marked for delete.

        By fetching with the STATE() = 'DELETED' clause.

	If they come back with a METHOD, then they are 'marked
	for delete' iTIP objects.

	If they come back without a METHOD, then they are marked
	for delete booked objects.

  o How do you mark an object for deletion.

	A special CMD?

		CMD:MARKDELETED

	A paramater to the DELETE command?

		CMD;opt=markfor:DELETE

   o Make the default to just fetch booked components so
     that you have to explicitly ask for deleted or unprocessed
     objects?