Subject: Re: 1.3 Defintions: BOOKED

From: [email-masked]
Date: Mon, 4 Nov 2002 17:07:04 -0500

Doug responded on 10/30/2002 03:18:34 PM:
> No, that won't work. Other reasons for the DELETED state are:
> 
>    Detection of duplicate iTIP messages
>         Your going to have to keep the entire object in
>       order to detect if it is a duplicate.

I dont recall seeing duplicate object detection by doing full object data 
comparison as a CAP requirement. 

Since all iCalendar objects are fully self-contained all you need is the 
UID, [RECURRENCE-ID,] SEQUENCE and DTSTAMP to detect if you have newer 
data then the object you are processing or not and so you can tell if you 
should ignore the object or not.  All other properties are extraneous to 
the issue of sequencing.

I strongly disagree w/the contention that my CS cannot actually delete an 
entry because it prevents some CUA from doing duplicate detection.  Since 
I see no way to undelete an entry marked as "DELETED" (but not actually 
deleted to any degree) and I see no mention of when these marked entries 
can actually be deleted I have a hard time swallowing the design w/o it 
expressly declaring that some form of soft deletion is in use.

>    Ignoring events for which you do not wish to attend.
>       If you keep getting a REQUEST for a meeting,
>       you can mark it as DELETED and then ignore any
>       updates.

This is some new functional ability I never knew was in CAP.  A CUA that 
can recall if I deleted a REQUEST on purpose and no longer want to see any 
REQUESTS or if I deleted a REQUEST by accident but want to stay involved 
or if I deleted a REQUEST on purpose but now want to get involved again. 
Wow, all that from a simple DELETE action.  Im very impressed.  And just 
how is this magic achieved?...

>                 In some cases you will want to remain
>       on the distribution list, even if you are not
>       going to attend a specific instance.

Again Im curious to know how the CUA achieves this magical state of 
enlightenment...

> AND
>    I do not recall this WG discussing ANY options that would
>    allow the CS or CUA to remove anything from the marked for
>    deleted objects.
> 
>    The only change to the object is it state.

So a deletion is just a change of state and never an actual removal?  You 
work for a storage maker or something?  All data becomes effectively 
READ-ONLY?  I cant actually physically delete those REPLYs I just 
processed??  Is it just more or does this sound like Bad Joss to others?

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: Mon, 04 Nov 2002 15:54:02 -0700

[email-masked] wrote:

> data then the object you are processing or not and so you can tell if 
> you should ignore the object or not.  All other properties are 
> extraneous to the issue of sequencing.

Feel free to modify the object - there is no CAP requirement
that CAP force a CS to do that :-)

> I strongly disagree w/the contention that my CS cannot actually delete 
> an entry because it prevents some CUA from doing duplicate detection. 

Could you please point out in CAP where it says that?
Or which e-mail I sent that said that?

>  Since I see no way to undelete an entry marked as "DELETED" (but not 
> actually deleted to any degree) and I see no mention of when these 
> marked entries can actually be deleted I have a hard time swallowing the 
> design w/o it expressly declaring that some form of soft deletion is in 
> use.

Again - feel free not use use that feature.
If I wanted to re-create it, I would just store an object
that looked like it - then remove the old marked for delete one.

> Again Im curious to know how the CUA achieves this magical state of 

By setting PARTSTAT == no to only that instance.

> So a deletion is just a change of state and never an actual removal? 

Nor was that said or written.

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

---

From: [email-masked]
Date: Tue, 5 Nov 2002 15:00:21 -0500

> that CAP force a CS to do that :-)

You suggested that all the properties must be preserved to do duplicate 

>       order to detect if it is a duplicate.

but thats not true for the reasons I cited so its not a justification for 
having a DELETED state but not actual deleting of entries.

CAP does not have any MUST/SHOULD/MAY/etc text to this effect but you 
still have the suggestion of it when you write:

                                                     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.

> Could you please point out in CAP where it says that?

Sure think.  In Draft 09-b-3 its on the bottom of p 18 and top of p 19:

                                                     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.

The same text is also in draft 09-b-2 (verbatim I think).  Perhaps its 
removed in draft 09-b-4...

> that looked like it - then remove the old marked for delete one.

So now this is an unspecified feature of CAP??...

This is all unspecified voodoo that is inconsistant behaviour from the 
CUAs point of view.  This is why I raise the entire issue of actual vs 
soft deletes (or as you say "marked for deletion").

If the spec is ambiguoius then implemenations will be ambiguous and not 
interoperate properly.  When that happens we've not done the job 
correctly.

> By setting PARTSTAT == no to only that instance.

PARTSTAT=DECLINED does not imbue the CUA w/any magical ability to deduce 
my intent!  It merely indicates to the CUA/CS that I declined 
participation in that entry or instance.  It cannot deduce if I did 
something by accident or on purpose NOR can it tell if I want to stay 
informed or not (actually that can be done via the RSVP property 
parameter) but this still remains some kind of voodoo thats unclear how it 
should be done by everyone...

> Nor was that said or written.

You just did.  A DELETE is not an actual deletion of the entry its only a 
"change to the object...state" (aka "marked for deletion" as is often used 
in the CAP draft).  How else is one to interpret:

                                                    In which case the
   "UNPROCESSED" state objects could be removed from the CS or the CUA
   could set those object to the marked for delete state.

The entry is "removed from the CS or ...marked for delete." is 2 distinct 
cases: actually removed from the CS or marked for removal from the CS. 
Just like most mail clients have a trash bin of some form where "marked 
for deletion" messages go before they are actually "removed from the" mail 
file, you have proscribed the concept of soft deleting an entry since you 
also allow it to be "marked for deletion", available for duplicate 
detection (or recreation/restoration) BUT its unpurgable from the system. 

This is all a digression from BOOKED state to the issue of deletions 
(although its relevant to the DELETED state).   I return to the original 
relevant portion I sent:

> On the topic of querying for deleted entries, we should clearly state 
> (preferably in 1.3) that no actual data is guaranteed to be returned for 

> a "DELETED" entry with maybe the exception of the UID (maybe...). 

Unless we unambiguously and categorically define how deletions are to be 
dealt with then we risk turning the DELETED state into the "recurrence 
rule of CAP"...

Bruce