Subject: Re: 2.2 Relationship of RFC-2446 (ITIP) and CAP: Soft deletes?

From: [email-masked]
Date: Mon, 4 Nov 2002 10:26:48 -0500

> >    The marked for delete state is used to keep the object around so 
that
> >   the CUA can process duplicate requests automatically.  If a 
duplicate
> >   [iTIP] object is deposited into the CS and there exists identical
> >   marked for delete objects, then a CUA acting on behalf of the 
"OWNER"
> >   can silently drop those duplicate entries.
> >
> > I cant help but thinking that we just created 'soft deletes' and are 
> > mandating that all CUAs/CSs implement them.
> 
> We did not 'just create' anything - it has been on the list for a long
> time (years?). And I assume when you say 'soft deletes' you are talking 
about
> the DELETED state?

I dont see any talk of the use of soft deletions in CAP in the archives. 
We have talked about deletion stubs (aka tombstones or tombstoning for 
those using FT indexes) but I dont see any discussion of the use of soft 
deletes.

I use the generic dB term "soft deletes" to indicate that the concept that 
'an entry is marked for deletion but has not yet been removed from the 
store' concept.  The information on and about that entry is therefore 
still available.  This makes the duplicate detection your text describes 
(1st line) possible.  If the entrys data has actually be deleted (it will 
happen eventually) and only some partial subset of the full entry is 
available for duplicate detection and the process of actual and accurate 
duplicate detection is no longer possible.

> The CS does not automatically do anything. The DELETED state exists
> for CUAs. If you do not want to tag objects as DELETED, then don't.

Hmm, now I see a slight discrepancy in nomenclature/usage.  I suspect the 
"DELETED" state is really a "Marked for removal" status instead of an 
indicator that the entry has actually been removed.  If this is the case 
then we need some way to clearly differentiate between the 2 states since 
some proscribed ablities are not possible in the latter case. 

We need to be able to detect both cases since both are going to happen.

> I can not find any text in CAP about 'silent deletions'.

Better go reread the citation then.  The text I was referring to (from 
09-b) was:

  the CUA can process duplicate requests automatically.  If a duplicate
  [iTIP] object is deposited into the CS and there exists identical
  marked for delete objects, then a CUA acting on behalf of the "OWNER"
  can silently drop those duplicate entries.

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