Subject: Re: No partial success when it comes to deletion?

From: [email-masked]
Date: Thu, 20 Feb 2003 13:24:58 -0500

Andrea replied on 01/31/2003 03:28:49 AM:
> Now, before I get carried away again: if the consensus is to have
> no transactions for now, I'm fine. 

I think that the general concensus is no transactions. 

> If you are still interested, read through ;-)

Rolling up my sleeves and forging ahead....

> > If ordering by TARGET is important to you then Id say that concurrent 
> > DELETEs on separate channels is the way you would probably want to go. 
 Or 
> > am I missing the root of the concern here?
> 
> It's not that which is worrying me, it's a matter of simplicity,
> consistency and regression tests to cover all possible cases. If one
> implementor gets one of the many cases wrong, we end up facing
> hard times...

Haha.  Have you been trying to do iTIP with Outlook lately?

As any long time lurker here can tell you Im a BIG fan of KISS.  The more 
complex and obtuse something gets to do even the simplest tasks is just 
asking for failure.

> > Not quite.  I think that atomicity of the command varys with the 
command. 
> > For example, a DELETE of a VEVENT in 1 VAGENDA succeeds and a positive 

> > VREPLY is sent back.  Then the attempted deletion of a different 
VEVENT 
> > fails.  Why should this make the first success now a failure??
> 
> That's what I say: the CS has no way of kowing, the CUA has some more
> hints.

It is NOT a matter of hints nor is it the CS concern really.  If the 1st 
VREPLY said I deleted a particluar VEVENT then _why_ would failing to 
delete a different VEVENT now cause that previous successful deletion to 
now become a failure?  If you use an eraser to remove some text on paper 
but cannot erase a second block of text, does that mean you did not 
actually erase the first block of text?  Of course not.  The first erasure 
worked, the second did not; its that simple.

Besides, what does the CUA need any hints for?  It gets the VREPLY with 
the success or failure REQUEST-STATUS line(s) in it.

> > Yeah, so?  The 1st and 2nd VAGENDAs allow you write permission so you 
can 
> > CREATE the invitation.  The 3rd does not (what a weenie for not 
wanting me 
> > to access their calendar!).  So does that mean that you were unable to 

> > invite the first 2 people?  Certainly not.  Does that mean the entire 
> > CREATE command should be failed?  Nope.
> 
> You could argue that and you would be correct. At the same time my HR
> manager who just wanted to book the meeting with the 3 guys would arguee
> that he wanted to meet all 3 of them, not 2, so the computer failed;
> and he'd be correct as well. :-P

Its not an issue of "the computer failed", its an issue of how to design 
CUAs to deal with and represent success and failures in a manner that CUs 
will expect/want/need.

<Ok, covering this gets a bit into the GUI realm and outside of CAP but 
Ill continue on.>

The HR Manager should easily be able to take some corrective action 
depending on the reason for the failure.  User3's calendar could be down 
for maintenance reasons (ie: compaction, etc.) or the attempt could have 
been blocked by VCARs or even the Manager somehow specified a TARGET that 
does not exist even.  All are equally plausible reasons for the failure. 
So just what could/should happen?...

The CUA could (should!) clearly indicate the failure in the UI and then 
let the manager decide what action to take (or take it automatically based 
on some CU preference/settings).  The CU could decide to leave it be and 
retry User3 later (the first and third causes) or it could indicate a 
temporary failure in the UI and retry User3 again at some later point. 
Alternately the CUA could display a warning that the Manager is prohibited 
from accessing User3's calendar (middle cause) and let the CU decide what 
to do. 

If the Manger can invite User1 and User2 then they could just as easily 
cancel/uninvite them if the manager chose to do so.  (I'm excluding the 
obvious case where a VCAR allows CREATEs where the METHOD != "CANCEL" only 
because even though its doable its stupid to do so IMNHO for obvious 
reasons.)

The CS is not sentient so it cannot guess what any pariticular CU/CUA 
wants done in the case of failure like this one.  Its something that can 
only be really accurately controlled by the CU (and by extension their 
CUA) so I think thats where the control should be; not in the CS but 
rather in the CUA.

> Now seriously: if the CUA gets back the error, it must take corrective
> actions. As a minimum it should change the VEVENT to show that the
> invitation failed (how?). 

Thats a UI issue really.  Also there is nothing to preclude the CUA from 
retrying again later (for those cases where failure is due to intermittant 
causes)...

I would assume that most CUAs would have some kind of queue of "things to 
take care of" so that the CUA can work "off-line" so its logical to say 
that the CUA would toss User3's invitation back into that queue with some 
status tracking info for the CUAs use.

I do not believe that failure for 1 TARGET is _automatic_ grounds for 
terminating the entire invitation process or putting it on the CUs own 
calendar for that matter.

>                             Surely it should ask the CU what to do now.

Sure (assuming there are no settings stored somewhere to indicate what 
kind of action to take already).

>                                                Also, as Doug mentioned,
> there could be a bot on one of the attendees VAGENDA which could act
> immediately on it etc.

Thats why the CUA should really CREATE it on the Organizers calendar 
BEFORE it tries to send out invitations.

> So no matter how you look at it, creating an event IS a transaction -
> we just get to pick whether it's implemented on the server or on the
> client.

Creating an event on my calendar and sending an invitation to 3 other 
users are two separate actions; they SHOULD NOT be combined into 1 
'transaction'.

Creating invitations for 3 other users has yet to be shown to be 
necessarily 1 "all or nothing" action that a single command MUST do 
entirely or must fail entirely.  See above.

I think that a properly designed CUA should have no problems dealing with 
the case above; its a matter of making sure the CUA (or CAP) does not 
combine multiple actions into 1 command.  The "Save and Send Invitations" 
UI button does NOT have to be a single CAP command.  UI actions are not 
(nor should they be) mapped 1-to-1 onto CAP commands.  "Retrieve Mail" is 
a single button/UI action but it translates into several POP3/IMAP4 
commands.  The same applys to CAP.

>                                     for instance, a CUA could first
> of all verify that all TARGETs exist, ask the CS if it has access
> to them etc. So that it could inform the CU even BEFORE she pressed
> the Ok button. 

Oh boy, this gets into Local and Server directory stuff and thats 
something Im sure many here would classify as Adminstration.  While I 
concur with you (Im used to Notes which do this) I think we'd be slapped 
if we go any farther down that path...

>                 In that case, failure would be really an exception.

The REQUEST-STATUS from each VREPLY is enough to distinguish intermittant 
from permanent, User Drain Bamage from Server side failure, etc.  Thats 
what the 1st number in the REQUEST-STATUS was intended for.  2.x was for 
permanent success, 1.x was for preliminary success, etc.

> But as things stand, even something as simple as a mistyped URI could
> cause a sequence of CAP commands, failure, phone calls ("look, I'm
> trying to accept your meeting proposal, but this darn program keeps
> giving me an error message!") etc. How do you handle all this?

If your CUA puts a bad address on the ORGANIZER property then its not my 
CUAs or CSs fault now is it!?! 

If I misentered the id in my CUA then I would not be able to send you the 
initial invitation so a REQUEST-STATUS:3.x;Unknown or invalid address;... 
would be the result my CUA would get back.  The 3 value tells the CUA its 
problem with something it sent.  See RFC 2445, Section 4.8.8.2 Request 
Status:

     |    3.xx      | Client Error. This class of status code       |
     |              | indicates that the request was not successful.|
     |              | The error is the result of either a syntax or |
     |              | a semantic error in the client formatted      |
     |              | request. Request should not be retried until  |
     |              | the condition in the request is corrected.    |

The more specific values under 3.xx are in iTIP and there should be more 
in CAP (although I havent checked this bit).

The REQUEST-STATUS code in the VREPLY should be crafted by the CS so that 
its accurate and that it conveys the proper status back to the CUA.  This 
feels more like a discussion on better CUA design at this point though...

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: [email-masked]
Date: Thu, 20 Feb 2003 13:48:01 -0500

Andrea wrote on 01/31/2003 03:39:03 AM:
> I just want to make sure we all realize avoiding transactions
> doesn't avoid the complexity per se, it just moves it to the CUA.
> Or, it allows you to write naive CUAs.

Its not an issue of being naive; its a matter of good design.

CUA designers should not expect to map a single UI action/button to just 1 
CAP command.  Your "Retrieve Mail" button in Outlook or Netscape Mail do 
NOT translate into 1 POP3 or IMAP4 command.  The same goes for CAP.

Perhaps we should add some Design Philosphy/Recomendations to the CAP 
draft so that CUA and CS designers do not expect 1 command to be the 
solution to every possible scenario there is or that may arise.  As Doug 
and I already noted some actions should precede others and failure for a 
latter action does not require undoing previously done actions.

> Ok, if this is the consensus I will agree.

Sounds like concensus then.  (We will of course revisit this in ~11 months 
when we forgot that we already covered it... ;^) )

> Then I will focus my effort on making sure nothing prevents the CS from
> implementing transactions when they are added down the road. Also, I 
will
> start working on a proposal for adding transactions later on. Ok?

Id love to read any drafts you have.

Bruce