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

From: [email-masked]
Date: Wed, 30 Oct 2002 15:04:31 -0500

Ok, maybe its just me but when I read in Section 2.2 Relationship of 
RFC-2446 (ITIP) and CAP:

   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.  If an entry is deleted there 
can be no guarantee that its data still exists.  As such its not going to 
be possible to perform accurate duplicate [iTIP] object detection.

If we are going to mandate soft-deletions be used (please NO!!) then we 
need lots more text to be clearer how all they should be implemented.

Im of the opinion that at most Ill want my CS to keep around a UID and 
RECURRENCE-IDs to do deletion detection with some course of action 
suggestions I can give my CU.   Detecting 'duplicate responses' may sound 
well and good but if I took the "merge the UNPROCESSED entries into a 
BOOKED entry" advocated in the draft then I may not want automatic 
detection and deletion to occur. 

For example: Doug ACCEPTs my invitation and I process it into my BOOKED 
entry and delete his ACCEPT message.  He then DECLINEs and then changes 
his mind and ACCEPTs again.  Should be CS detect his 2nd ACCEPTance and 
toss it leaving me w/just a DECLINE??  Nope.  The same goes for multiple 
COUNTERs, etc.

The only times deletion detection is helpful (in my view) are cases like:

I accidentally deleted an entry I was invited to and I call and have the 
Organizer re-invite me so I can add it to my calendar again.
I purposely deleted a meeting Im the Organzier for and sent out 
CANCELation notices to my Invitees.  Some didnt get it and send me 
COUNTERs, REPLYs, etc.  Detecting this allows me to craft a new 
cancellation notice.

If the CUA wants to be nice for me as described then it would toss away 
the new REQUEST in the former example and likely flounder and do nothing 
in the latter case.

The only way for the CUA to detect the deletion is to do a query for a 
deletion 'hit' for every UNPROCESSED entry its dealing with.  Sounds like 
LOTS of overhad I want to avoid...

Can we strike this bit about doing silent deletions since it implys so 
much baggage?...

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, 30 Oct 2002 14:51:04 -0700

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

 >  If an entry is deleted there can be no guarantee that its
 > data still exists.

I guarantee you: if you delete the data - it does not exist.

 >  As such its not
> going to be possible to perform accurate duplicate [iTIP] object detection.

So don't delete the data - mark it for delete (aka DELETED state).

> need lots more text to be clearer how all they should be implemented.

Bruce - this topic has been on the list for YEARS. This is nothing new.

> suggestions I can give my CU.   Detecting 'duplicate responses' may 
> sound well and good but if I took the "merge the UNPROCESSED entries 
> into a BOOKED entry" advocated in the draft then I may not want 
> automatic detection and deletion to occur.  

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.

> toss it leaving me w/just a DECLINE??  Nope.  The same goes for multiple 

I think you are confusing marked for delete (DELETED state) and removing
the object from the store. See the DELETE command.

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

> Can we strike this bit about doing silent deletions since it implys so 

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

> Bruce Kahn                                INet: [email-masked]

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