Subject: No partial success when it comes to deletion?

From: Doug Royer <[email-masked]>
Date: Sun, 12 Jan 2003 13:24:53 -0700

I would like to add this text to the DELETE command in CAP:

	There is no partial success for a "DELETE" command. Ether
	everything succeeds or nothing is done. So if the VREPLY
	contains X number of successful replies and at least
	one (1) failure then no objects were deleted or marked
	for deletion. This is because a malformed "QUERY" property
	value could have devastating effects and unintended
	deletion of some objects could make a calendar unusable.
	The CUA could inform the CU that their request must
	be modified in order to succeed.

Comments?

-
Site note: I am about 80% done with removing the duplicate
descriptions from CAP - I will be posting the proposed update
(which includes the above text which I can delete if there are
objections) in a few days.

-- 

  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: Andrea Campi <[email-masked]>
Date: Mon, 13 Jan 2003 10:36:56 +0100

> 	be modified in order to succeed.

I still think (as briefly mentioned before) that we should clearly
define failure modes for all commands. The text you are proposing
implies that all other commands can partly fail, but this is not
clearly stated anywhere (that I recall - I might be wrong).

I think that MODIFY and maybe MOVE need the same as what you are
proposing. CREATE is a judgement call - on one side, it isn't
as dangerous; on the other side, it would be if all commands that
modify data behaved the same.
Personally, I'd prefer this to be discussed in a common paragraph
before the commands, not in each command description.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: John Stracke <[email-masked]>
Date: Mon, 13 Jan 2003 09:55:10 -0500

>modify data behaved the same.
One note: an implementor that makes DELETE and CREATE atomic will have a 
much easier time making MODIFY and MOVE atomic, too, since you could do 
it as "CREATE modified/moved components, DELETE originals, commit".  So, 
if the spec says DELETE and CREATE are atomic, then probably MODIFY and 
MOVE should be, too.

Let's see...MODIFY can modify two properties at a time, can't it? If so, 
then I'd say it should definitely be atomic, at least within each 
component; the opportunities for confusion are just too great, when 
you're changing properties that affect each other.  Consider what 
happens if you're rescheduling an event, and changing the TZID at the 
same time; someone could wind up seeing the old TZID but the new 
DTSTART.  Atomicity across components--being assured that none of them 
will change until they all do--is probably less important.

Atomicity does complicate the implementations; but it's possible to 
provide it relatively simply.  A low-end CS that doesn't need to perform 
wonderfully could simplify its atomicity requirements by serializing its 
writes--instead of doing full-fledged rollback logs, it could lock down 
the store while doing a write, and only have one outstanding write at a 
time.  And, of course, any CS built on an RDBMS can just piggyback on 
the DB's own rollback.

-- 
/================================================================\
|John Stracke      [email-masked]                         |
|Principal Engineer|http://www.centive.com                       |
|Centive           |My opinions are my own.                      |
|================================================================|
|Excuse me. I've been dead lately, and my brain isn't working too|
|well. --Miles Vorkosigan                                        |
\================================================================/

---

From: Andrea Campi <[email-masked]>
Date: Mon, 13 Jan 2003 16:44:36 +0100

> you're changing properties that affect each other.  Consider what 

Exactly.

> will change until they all do--is probably less important.

Possibly, but as a minimum we must define if we guarantee atomicity or not.

> provide it relatively simply.  A low-end CS that doesn't need to perform 

I agree with your considerations but they are not all that is involved.

For instance, my CS does things in this order:

 - look at all queries (we may have more than one in the same command), if
any of them is invalid fail entire command
 - look at all targets, if any of them is invalid fail entire command
 - perform command in order

Oh and by the way: there is confusion in the draft regarding whether
an error should stop command processing and rollback immediately, or
processing goes on to the end in order to report all errors. This needs
to be clarified as well.

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Mon, 13 Jan 2003 10:20:31 -0700

Andrea Campi wrote:
>> ...

Yes.

> modify data behaved the same.

MODIFY already has that restriction:

    If any error occurred:

       No component will be changed at all.  That is, it will appear just
       as it was prior to the modify and the CAP server SHOULD return a ...

I think that CREATE does not need that restriction. I would
be happy ether way.

> before the commands, not in each command description.

Of the commands I would say:

	CMD		My thoughts
	---		------------

	ABORT		Does not apply as there is no partial failure.
	CONTINUE	Does not apply as there is no partial failure.
	CREATE		Maybe an issue - YES
	DELETE		YES
	GENERATE-UID	Does not apply as there is no partial failure.
	GET-CAPABILITY	Does not apply as there is no partial failure.
	IDENTIFY	Does not apply as there is no partial failure.
	MODIFY		YES
	MOVE		YES
	REPLY		Does not apply as there is no partial failure of REPLY
	SEARCH		Does not apply as partial failures cause no harm.
	SET-LOCALE	Does not apply as there is no partial failure.
	TIMEOUT		Does not apply as there is no partial failure.

It it would only apply to 3 commands not all of them.
Correct?

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 13 Jan 2003 10:28:48 -0700

> if the spec says DELETE and CREATE are atomic, then probably MODIFY and 

I agree.

> will change until they all do--is probably less important.

I agree - it is too dangerous to not make them atomic and
there are simpler ways to do it than rollback.

--

---

From: John Stracke <[email-masked]>
Date: Mon, 13 Jan 2003 12:42:44 -0500

> I think that CREATE does not need that restriction. I would

Let's see.  A partial failure can certainly occur--say, if the system 
has enough disk space for the main VEVENT, but not for the VTIMEZONE in 
contains.  In that case, the VEVENT would be invalid--and we probably do 
want to make sure that we don't put invalid iCalendar components into a 
CS, don't we?

-- 
/=================================================================\
|John Stracke      [email-masked]                          |
|Principal Engineer|http://www.centive.com                        |
|Centive           |My opinions are my own.                       |
|=================================================================|
|"And bring the search warrant." "You mean the sledgehammer, sir?"|
|"Yes."                                                           |
\=================================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 13 Jan 2003 12:00:36 -0700

> want to make sure that we don't put invalid iCalendar components into a 

If there are no objections I'll add that restriction to

	CREATE
	DELETE
	MODIFY
	MOVE

I'll add a general note at the top level describing the issue.
I'll add a specific note to each of the 4 commands saying
it applies to 'this' command.

--

---

From: [email-masked]
Date: Wed, 22 Jan 2003 12:16:14 -0500

>    be modified in order to succeed.

Whoa!!  This design change makes DELETEs into a transactional model 
command; something we _dont_ need.  That is, there can be multiple entrys 
deleted that only actually get really deleted once all of them happen 
successfully.  I VERY VERY strongly disagree with this design change. 

There are perfectly normal reasons why some deletions could fail: 
insufficient access, concurrent use by another CU, system maintenance on a 
VAGENDA, etc..  The new text creates a very very heavy burden on any CS 
implementor as they MUST now have a back end storage engine that does 
transactioning (in the DB sense of the term).  They can no longer use just 
any back end engine that can remove records in the store.

I strongly disagree w/this raising of the bar w/o any clear motivation for 
why it needs to be done.  So what if 1 of my TARGETs fails to DELETE but 
my other 2 succeed??  Whats wrong w/that if the CS can clearly indicate 
this in the VREPLYs?? 

  This can also be used as a justification for making the rest of the 
commands fully transactional ("Only successflly create and save the entry 
if I can save it on ALL of the TARGETs.", etc).  I dont think we want to 
fall down that very very slippery and nasty slope just yet do we?

  Pardon me if this was already said but I wanted to make sure before I 
get sucked into some Real Work(TM) stuff.

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: Wed, 22 Jan 2003 14:51:04 -0500

Andrea wrote on 01/13/2003 04:36:56 AM:
> define failure modes for all commands. 

Isnt that already accomplished by the delete-reply (or any *-reply in the 
ABNF) that gets sent back for each TARGET??  The success or failure can be 
conveyed by the request-status?  Isnt that why we have request-status?  Or 
is there just something Im missing as I try to get back up to speed on 
missed traffic?

>                                        The text you are proposing
> implies that all other commands can partly fail, 

Id state it somewhat differently in that the DELETE, or any other command, 
worked or not but the individual results, say per TARGET, can vary.  If I 
cannot remove a VEVENT from a TARGET due to a VCAR then did the DELETE 
really fail?  It worked for all the cases where I could actually delete. 
The command _itself_ did complete; just not all of the results were 
'positive'!

Bruce

---

From: [email-masked]
Date: Wed, 22 Jan 2003 15:14:18 -0500

> time.

Hahaha.  Do you really think that anyone building a CS NOT on top of a 
RDBMS is going to actually destroy and mangle their performance on purpose 
so they can serialize their writes and reads like that??!  EVERY operation 
would have to wait to make sure that ALL the TARGETs were singularly 
available before it could proceed with any operation!  Yeah, that's a 
really great design Id love to see implemented.  Scales real well too...

Doug's stated intent in proposing this new text was "because a malformed 
"QUERY" property value could have devastating effects and unintended 
deletion of some objects could make a calendar unusable."  There is a 
distinct difference between a 'malformed' query and one that's just 
running amok but properly formed.  NO command should attempt to do any 
work if there is bad data in the command or bad parameters on the command. 
 That is, if the VQUERY is improperly formed then the command itself 
should immediately fail.  That's a totally different case than if the 
query for "all VEVENTS and VTODOs on my jerk bosses calendar" is sent on 
the DELETE.  If I properly craft a malicious query that's very different 
than if I miscraft a well meaning one.

I am strongly against essentially mandating that the CS MUST have an RDBMS 
back end because I don't see that its necessary.  We've taken pains to 
define a relatively abstract data and system model but this new text just 
nukes all that effort with no demonstrable gain or need.  In addition, if 
we ever get back to considering multi-CS commands (TARGETing calendars in 
other CS, the old fanout issue we dropped for CAP 1.0) then not even an 
RDBMS will save you as I know of none that work across multiple actual 
servers.

I would be strongly in favor of some text that puts strict behavior 
controls on stuff like improperly formed commands or requests.  Something 
like "If the parameters or data in the command are incorrectly formed or 
unparsable then the command MUST fail, log a message and put a black tick 
next to that users name in their personal file."  Ok, that last bit may be 
overkill but the rest I still like.  This is akin to what Andrea was 
asking for too...

Bruce

---

From: [email-masked]
Date: Wed, 22 Jan 2003 15:23:32 -0500

>  - perform command in order

This does not match the proposed texts intent.  Doug's motivation was 
"because a malformed "QUERY" property value could have devastating effects 
and unintended deletion of some objects could make a calendar unusable." 
However the new text starts with:

                                                                 Ether
                 for deletion.

This all means that if there were any failures in your "-perform command 
in order" then the command would fail; it does not just match your first 
two lines.

I agree w/you (see last msg) that the command itself should fail if there 
is any problem w/the parameters or inputs to it; it should succeed 
otherwise.  Any failures during your "-perform command in order" step is 
NOT grounds for failing the entire command!  There was nothing wrong w/the 
command itself, the 'problem' was due to something else and not 
necessarily anything malicious even!

Bruce

---

From: [email-masked]
Date: Wed, 22 Jan 2003 15:33:29 -0500

> Of the commands I would say:

Not quite.  Nearly all commands could fail. 

For example, the Admins has begun system shutdown so no new commands 
should be accepted.  Thus, instead of keeping the CS up as GENERATE-UIDs 
(or CONTINUEs or ...) come in, the command would fail with an appropriate 
reponse like "REQUEST-STATUS:6.5;System shutdown in progress\, no new 
commands accepted." as the reply.  The same goes for the CONTINUE and 
nearly all commands.  ABORT may be the sole holdout (REPLY is not a 
command)...

Bruce

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 22 Jan 2003 15:45:47 -0500

Date: Mon, 13 Jan 2003 09:55:10 -0500
   From: John Stracke <[email-masked]>
[...]
   Atomicity does complicate the implementations; but it's possible to 
   provide it relatively simply.  A low-end CS that doesn't need to perform 
   wonderfully could simplify its atomicity requirements by serializing its 
   writes--instead of doing full-fledged rollback logs, it could lock down 
   the store while doing a write, and only have one outstanding write at a 
   time.  And, of course, any CS built on an RDBMS can just piggyback on 
   the DB's own rollback.

What if the server fails in the middle of the operation? Is it
acceptable that the operation is half-done?

I don't think atomicity requirements are as burdensome as Bruce thinks
they are, but if you're going to add them there should also be text
about server failures. Requiring servers to maintain atomicity even
when they crash is considerably more burdensome. (I suspect it can be
left as a quality-of-implementation issue.)

Larry

---

From: [email-masked]
Date: Wed, 22 Jan 2003 15:49:46 -0500

> If there are no objections I'll add that restriction to

I object to the proposed text as it essentially mandates that the CS be 
built on an RDBMS of some kind.  I do NOT object to the intent of 
requireing ALL commands to safety check their _inputs_ prior to actually 
performing said command.  The success or failure of individual TARGETs is 
NOT grounds for failing ALL TARGETs!!

WRT to Johns concern: The VEVENT should NOT be CREATEd if the entire 
creation cannot be completed for that TARGET.  That is, the CREATE command 
is creating the event and the definition in the store so either it works 
and both are there or it fails and neither are there.  The VEVENT MUST NOT 
be created and left if the command for that TARGET fails!  Otherwise any 
failures would result in all kinds of cruft being left in the TARGET!

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 22 Jan 2003 20:25:15 -0700

[email-masked] wrote:
> insufficient access, concurrent use by another CU, system maintenance on 
> a VAGENDA, etc..  The new text creates a very very heavy burden on any 
> CS implementor as they MUST now have a back end storage engine that does 
> transactioning (in the DB sense of the term).  They can no longer use 
> just any back end engine that can remove records in the store.

Good points.

--

---

From: Andrea Campi <[email-masked]>
Date: Thu, 23 Jan 2003 13:08:36 +0100

> failures would result in all kinds of cruft being left in the TARGET!

Let me try to summarize the options I see:

1 - each part of the command succeeds or fails on its own

2 - the CS MUST do all the checking upfront, then:
	- if at least one part of the command fails validation, it MUST bail
out immediately, returning appropriate REQUEST-STATUS
	- if all parts pass validation, the CS proceeds to execute the
commands; each of them is handled separately, it can fail or succeed, as
long as the CS returns an appropriate REQUEST-STATUS

3 - same as #2, except in case of error during command execution the
CS bails out immediately without REQUEST-STATUS for the remaining
parts

4 - same as #2, except the CS rollbacks everything and turns
REQUEST-STATUS success into "would have succeeded"

5 - same as #3, except the CS rollbacks everything and turns
REQUEST-STATUS success into "would have succeeded"

Note that I used the voluntarily vague expression "part of a command", because
in fact we have a lot of variations: commands can act on more than one target,
MODIFY can match lots of components, etc etc. I consider "part of a command"
to be an atomic item, and we need to decide what constitutes an atomic item.
In John's example, VEVENT+VTIMEZONE would be an atomic item in my discussion
above.

Bye,
	Andrea

---

From: [email-masked]
Date: Thu, 23 Jan 2003 15:43:40 -0500

> left as a quality-of-implementation issue.)

The burden will depend on what kind of back end engine your CS uses and 
how the data is stored.  If your CS uses an RDBMS then you can utilize the 
engines transactioning abilities.  If a CS uses a model like keeping each 
VAGENDA in a separate file or directory then the burden is much much 
greater  (managing semaphores, deadlocks, delayed I/O, etc).

In any case the proposed text does NOT address the proposed motivation for 
it. 

I am all for mandating that any command MUST fail if the inputs or 
parameters to it are bad.  Is anyone really opposed to that??

I am against saying that individual failures of any kind are grounds for 
failing ALL the actions attempted.  Just because a VAGENDA or actual entry 
is 'unavailable' for any number of reasons does not mean that the others 
that were available and already deleted should NOT be completed as 
expected.  (After all a VREPLY with a success response was already sent 
back).  I for one do not think that mandating a CS essentially be built 
like an RDBMS just to prevent possibly legitimate failures from undoing 
legitimate successes is a good thing.

Why add ANY burden when there is no justification for even doing so?

Bruce

---

From: Lawrence Greenfield <[email-masked]>
Date: Thu, 23 Jan 2003 15:55:29 -0500

From: [email-masked]
   Date: Thu, 23 Jan 2003 15:43:40 -0500
[...]
   The burden will depend on what kind of back end engine your CS uses and 
   how the data is stored.  If your CS uses an RDBMS then you can utilize the 
   engines transactioning abilities.  If a CS uses a model like keeping each 
   VAGENDA in a separate file or directory then the burden is much much 
   greater  (managing semaphores, deadlocks, delayed I/O, etc).

Yes, I understand this very well.

It is obvious to me that servers should not tolerate any amount of
broken protocol. I'm definitely in the "be liberal considered harmful"
camp of the applications area---servers should strictly enforce all
syntax to prevent bad client implementations from ever getting out
into the real world.

>    be modified in order to succeed.

is ridiculous. The calendar server should never return a successful
VREPLY for an action not taken. This would be highly unintuitive and I
am very against this proposal.

I think it would be more reasonable to say that commands must
completely succeed or completely fail; having a VCALENDAR object
result in either X successful replies OR X failures.

Another possibility would be to add a parameter so that clients could
request atomic behavior from the calendar server (";ATOMIC"?), and
that servers SHOULD respect the client's request. (It then turns into
a quality-of-implementation issue if they do or don't.)

In all cases the server's VREPLYs must accurately reflect what actions
were performed.

Larry

---

From: Doug Royer <[email-masked]>
Date: Thu, 23 Jan 2003 14:25:06 -0700

I agree with Bruce. I was looking at it from an RDBMS point of view.
It will make simpler devices much harder to implement. They tend
to be thin clients or memory restricted anyway.

And this debate has also reminded me that we had agreed a long
time ago in CAP to NOT to do any kind of transaction locking.

We can do that as an optional add-on later.

> failing ALL the actions attempted.  Just because a VAGENDA or actual 
> entry is 'unavailable' for any number of reasons does not mean that the 
> others that were available and already deleted should NOT be completed 
> as expected.  (After all a VREPLY with a success response was already 
> sent back).  I for one do not think that mandating a CS essentially be 
> built like an RDBMS just to prevent possibly legitimate failures from 
> undoing legitimate successes is a good thing.

--

---

From: John Stracke <[email-masked]>
Date: Thu, 23 Jan 2003 16:45:45 -0500

> to be thin clients or memory restricted anyway.

Why would a CS be a thin client?

-- 
/===============================================================\
|John Stracke      [email-masked]                        |
|Principal Engineer|http://www.centive.com                      |
|Centive           |My opinions are my own.                     |
|===============================================================|
|The Net was designed to survive nukes, but not lawsuits. Wait a|
|minute.                                                        |
\===============================================================/

---

From: Doug Royer <[email-masked]>
Date: Thu, 23 Jan 2003 17:13:51 -0700

> Why would a CS be a thin client?

PDA

--

---

From: Andrea Campi <[email-masked]>
Date: Fri, 24 Jan 2003 10:36:56 +0100

> back).  I for one do not think that mandating a CS essentially be built 

Sorry? You mean, if the command succeeds for one target and fails
for another one, right? But in any case, that's an implementation
detail - you can't assume anything about when exactly the VREPLY
gets sent. That's what worries me more about the protocol specification:
if my CUA sends a command with multiple TARGETs, there's not telling
whether the response will be one RPY or multiple ANS, whether any
of them will be a complete VCALENDAR component, which of them
contains the reponse for which TARGET, and so on - not until it
parses everything. There are so many ways of doing the same thing!

Anyway, back to the discussion. You still assume it IS meaningful
to assume commands are not atomic; I contend that the CS simply
has no way of knowing. Compare the following:

 - delete every components more than a year old on both of my VAGENDAs

BEGIN:VCALENDAR
CMD:DELETE
TARGET:work
TARGET:personal
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE ....
QUERY:SELECT * FROM VTODO WHERE ....
END:VQUERY
END:VCALENDAR

 - propose two different but related meetings, book it on my VAGENDA

BEGIN:VCALENDAR
CMD:CREATE
TARGET:attendee1
TARGET:attendee2
TARGET:attendee3
METHOD:REQUEST
BEGIN:VEVENT
...
END:VEVENT
BEGIN:VEVENT
...
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR
CMD:CREATE
TARGET:work
BEGIN:VEVENT
...
END:VEVENT
BEGIN:VEVENT
...
END:VEVENT
END:VCALENDAR

I can agree #1 doesn't need to be atomic - if I get any failure
I can simply retry.

In case #2, I would actually love to be able to perform both CREATE
as a single atomic transaction. Unfortunately, there's no way I
can do that.
Failing that, I surely want each CREATE to be an atomic transaction.
What if there is an error, any kind of error, on one out of three
VAGENDAs? If the CUA wants to retry it would need to either rollback
(via DELETE), or change the original command to eliminate for TARGETs
it already succeeded. And in case the error is non transient and
CU intervention is required, it needs to either remember this.
Couple this with the effective impossibility for a CUA to know
whether it has permission to store into a TARGET (without retrieving
the VCARs and trying to determine that by itself, that is).

Look, I can see your point, but I see no reason why unreasonably
simplistic implementations should effectively crimple the ability
to have elegant and efficient implementations. It's not like we don't
have free RDBMS after all...

Bye,
	Andrea

---

From: John Stracke <[email-masked]>
Date: Fri, 24 Jan 2003 09:28:41 -0500

>> Why would a CS be a thin client?

Um.  OK, I know we've discussed this before, but I never did grasp the 
utility.  Sure, a PDA usually has a CUA with, in effect, its own 
calendar store (usually a file or some such); but I don't see why that 
CS would be exposed via CAP.  If you want lightweight, you don't put the 
CS into a separate process on the PDA; you integrate the CS access into 
the same process as the CUA.

Or are you talking about having a remote CUA or CS CAP into the PDA to 
sync with its CS?

-- 
/=======================================================\
|John Stracke      [email-masked]                |
|Principal Engineer|http://www.centive.com              |
|Centive           |My opinions are my own.             |
|=======================================================|
|Two words that do not go together: "Memorial Cookbook".|
\=======================================================/

---

From: [email-masked]
Date: Fri, 24 Jan 2003 13:24:45 -0500

> out immediately, returning appropriate REQUEST-STATUS

I think that we are talking different levels / concepts here. 

When I see "command fails validation" I think "Are the parameters and the 
inputs to command X valid and properly formed and is the requestor 
permitted to issue command X?  If so, they are valid and I can try to do 
command X for the requestor."  It sounds like you are treating command 
validation as "Will command X work for all TARGETs for the requestor?". 
These are two very distinct issues.  Before we can go further Id like to 
check if this is a correct analysis of your thoughts...

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Mon, 27 Jan 2003 13:01:00 +0100

> check if this is a correct analysis of your thoughts...

I think we agree, I define "command validation" as "Are the parameters and the
inputs to command X valid and properly formed". I didn't think of your " is the
requestor permitted to issue command X?" but that's logical, too.

This I see as the first phase, and if the check is passed the CS
can attempt to execute the command - but it can still fail for
some or all targets, for transient or permanent reasons.

Now we can go further ;-)

Bye,
	Andrea

---

From: [email-masked]
Date: Wed, 29 Jan 2003 13:06:07 -0500

> requestor permitted to issue command X?" but that's logical, too.

I think I should clarify something WRT that last bit.  In Notes/Domino we 
have the concept of "Who can access the server", "Who can create new 
databases", etc. so in our frame of reference its valid for me to be able 
to access the server and databases on it (read calendars there when 
thinking CAP) but I may not be allowed to delete from the server.  This 
was what I was thinking when I wrote that last bit.  Of course such access 
control is CS Administration and OOB for CAP 1.0 but its a factor...

In Notes/Domino a database (ack: calendar) can also have some restrictions 
on them so while the server may allow me to delete, the particular db may 
not.  This is akin to the VCARs that prevent me from removing stuff from 
someone elses calendar and would result in a VRESULT to that effect rather 
than the command failing itself.

This sounds a bit like having my cake and eating it too but its not 
really.  The "Can Bruce delete/create stuff from/on the CS" check is 
different from "Can Bruce delete stuff off of Pats and Bobs calendars". 
The former is really "Is Bruce allowed to try any deletions w/in the 
server?" and the latter is "Does Pat allow Bruce to delete from his 
calendar?" and "Does Bob allow Bruce to dlete from his calendar?".  The 
former results in an up front check of the attempted command and complete 
outright rejection of it.  The latter results in letting the command be 
attempted subject to access rights on the individual dBs (sic, calendars) 
where it may work for some and not others.

I also want to be clear that Im not proposing this kind of policy stuff be 
added to CAP; I was merely using it as part of getting clarifcation from 
Andrea.  (Of course that doesnt preclude me from coding my CS to do that 
now does it..?)

> Now we can go further ;-)

Ok, as typical you and I seem to be in agreement (it was just a phrasing 
quandry).  So my next question is do you agree (w/Dougs text) that any 
failures should result in the automatic negation of any previously 
returned VREPLYs that were successful?

I think we all like the idea of expresslly codifying the behaviour 
required for any implementation as described above to prevent poorly 
formed commands from causing havoc.  As I noted before, there are lots of 
perfectly valid reasons that a DELETE command could fail so I strongly 
disagree w/the proposal there. 

I also think that the implicit requirement of an RDBMS backend though has 
not been justified to warrant the change yet.  Is there some reason that 
Im just not seeing that would warrant an RDBMS backend for a CS at this 
point?

Bruce

---

From: Andrea Campi <[email-masked]>
Date: Thu, 30 Jan 2003 12:13:46 +0100

> disagree w/the proposal there. 

See my message with Message-ID <[email-masked]> for an
example of why I think we need some kind of atomicity, or transactions.
Did you miss it or did you find it irrelevant?

So yes, I guess I agree with Doug - but only if we go this way for all
commands. This is an all or nothing thing, we either support transactions
or we KISS.

> Im just not seeing that would warrant an RDBMS backend for a CS at this 

The main reason is one of simplicity. No matter how you look at it,
if we don't have transactions, the CUA will need to be more complex.
Moreover, a CUA might not be able to rollback a partially failed
command (because of VCARs if nothing else).

Is this a reasonable tradeoff? I don't think so, but it might be
that I'm looking things from a different perspective.

What about having optional support for transactions? This means:

 - a capability which tells us if the peer supports transactions
 - and either
   - a parameter that indicates if this command should be handled
     as an atomic transaction, or
   - explicit BEGIN, COMMIT and ROLLBACK commands.

Granted, all of this (exp. if we want to add 3 commands) could be in
a separate RFC, if you (plural) don't want to touch on this yet.

Bye,
	Andrea

---

From: [email-masked]
Date: Thu, 30 Jan 2003 15:27:02 -0500

> Did you miss it or did you find it irrelevant?

I missed it.  Its in my archive but its flagged as unread so I must have 
overlooked it somehow.  Ill go take a gander at it now...

Bruce