Subject: CAP: To delete or not to...

From: [email-masked]
Date: Wed, 13 Nov 2002 14:41:06 -0500

The issue of actual deletion vs 'marked for deletion' never got resolved. 
I think its something that absolutely MUST be resolved and in a very 
unambiguous way before we can pass WG Last Call.

The 09-submitted draft implys that actual deletes are performed by the CUA 
with text like:

2.2 Relationship of RFC-2446 (ITIP) and CAP
...
                                  Other CAP commands such as
   "DELETE", "MODIFY" and "MOVE" command values provide direct
   manipulation of components.
...
   followed by a "DELETE" command to remove any related old [iTIP]
   objects from the CS.
...
                                          Finally, the CUA could do a
   "DELETE" command to remove the related "UNPROCESSED" state objects.

and

10.1.5 DELETE Command

   CMD: DELETE

   Purpose: The "DELETE" command physically removes the QUERY result
   from the store or marks it for deletion.
...
   The "DELETE" command is used to delete calendars or components.  The
   included "VQUERY" component(s) specifies the container(s) to delete.

   If a component is to be marked for delete and not physically removed,
   then include the "OPTIONS" parameter with its value set to the "MARK"
   value in order to alter its state to "DELETED".

In some citations you will note the clear distinction between actual 
deletion and marking for deletion.

However no where is there any text dealing with what can be done on 
entries marked for deletion but not actually removed.  As such the 
essentially go into limbo.  This is not good unless you are a storage 
manufacturer. 

The possible choices for dealing w/marked for deletion entries is to:

1) Allow some way to restore them to full health (aka "Undelete" them) or 
2) Clearly state that they are as good as actually removed, can never be 
restored and will be actually removed at some point later at the CS 
discression (its an administration issue now...)

There are technical hurdles taking either approach we can dive on later 
but I think we need to reach WG concensus about deletions and if these 
"marked for deletion" (aka soft-deletes in my dB world) are something we 
want/need and then we can address the hurdles based on that choice.  If 
folks think that knowing the hurdles first is important we can lay them 
out first...

In any case, I think that having actual deletions and 'marked for 
deletion' requires more than 3 states we have defined in Section 1.3 now 
(Booked/Unprocessed/Deleted) since some text implys that any kind of 
deleted entry can be read.  For example:

      3.  A "DELETED" state entry is created by sending a "DELETE"
          command with the "OPTION" parameter value set to "MARK".  To
          retrieve any deleted object, simply do a query asking for any
          objects that were stored in the "DELETED" state.

As the new text says the "DELETED" state is if OPTION=MARK is set then the 
entry is DELETEd.  It does not define the state of the entry when the 
CMD:DELETE is used w/o OPTION=MARK...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Nov 2002 15:32:25 -0700

> essentially go into limbo.  This is not good unless you are a storage 

You can remove them. Why do you think that you can not?

> 1) Allow some way to restore them to full health (aka "Undelete" them) or

That was covered in my e-mail. What did you think of my comments?

> discression (its an administration issue now...)

It is up to the CUA to remove them from the CS.

> As the new text says the "DELETED" state is if OPTION=MARK is set then 
> the entry is DELETEd.  It does not define the state of the entry when 
> the CMD:DELETE is used w/o OPTION=MARK...

Yes it does:

If MARK is not set - it is physically removed.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Mon, 18 Nov 2002 13:11:05 -0500

> You can remove them. Why do you think that you can not?

Its very vague how you actually remove them.  Given the defition of 
"DELETED":

                                                                    To

Im guessing that the only way to actualy delete them after marking them as 
deleted is to:

1: Query for any entry in the DELETED state and
2: Re-DELETE them using a second DELETE command w/o the OPTION=MARK

but this is only my guess.  Its totally undefined how this happens or when 
it happens.

Taking a step back, I think that part of my issue is that a CUA can mark 
entries as DELETED but not actually remove them.  The entries that get 
DELETEed can be marked as "DELETED" but their behaviour/impact as entries 
is still totally undefined. 

Examples of the vagaries:

Should a "DELETED" entry still affect my busytime? 
Since the entry is not actually deleted is it possible to "undelete" them 
by simply querying the entry out and then resaving it w/a CREATE or other 
command? 
Once a CUA markes an VEVENT for deletion then what response should it get 
back on a query like "Give me the ATTENDEEs for the VEVENT with 
UID:123456789@blech" if the entry is deleted? 
Will there be some way to know that it needs to include a "AND STATE() = 
'DELETED'" or will it have to guess if there is a failure?
It is a failure to re-DELETE an entry thats already DELETED?

I can see the use of the DELETE command in a, shudder, sync process that 
is to be built later on but its current behaviour needs to better codify 
what the expected behaviour/results are for entries that are only marked 
for deletion, etc.

> That was covered in my e-mail. What did you think of my comments?

Im sorry, I must have missed them.  Ill try to go and find them...

> It is up to the CUA to remove them from the CS.

Again, exactly _how_ does the CUA find and remove said entries?  Also, why 
is it not something the CS can do per some CS policy (ie: "Deleted entries 
are automagically removed from the system 14 days after being marked for 
deletion.")??

> If MARK is not set - it is physically removed.

Ugh, my bad.  I was looking for text that said expressly that the DELETE 
command would physically remove the entry by default.  I didnt make the 
inference based on the cited text.

Bruce