Subject: Re: CAP Draft 6 comments

From: "John Stracke" <[email-masked]>
Date: Fri, 21 Dec 2001 10:47:50 -0500

>  Beside efficiency, there is another fundamental difference 
>between a "move" and a combination of "search", "create" 
>and "delete". The "move" command is atomic,

That's not necessarily a trivial requirement, you know.

>and since there is 
>no transaction in CAP, "search" + "create" + "delete"  is not.
>
>  This makes it very hard (impossible?) for a CUA to implement 
>a safe move. 

Yeah, well, there are different kinds of safety.  In this case, safety 
from errors in the CS is competing with safety from errors in the security 
design.  The security design is longer-lived than any one CS.

/================================================================\
|John Stracke                   |Principal Engineer              |
[email-masked]  |Incentive Systems, Inc.         |
|http://www.incentivesystems.com|My opinions are my own.         |
|================================================================|
|I'm on a Mission From God to Save The World from megalomania!   |
|(Question: which God? Answer: Milhouse, God of Humility. You    |
|probably haven't heard of him; he doesn't put himself forward.) |
\================================================================/

---

From: Patrice Lapierre <[email-masked]>
Date: Fri, 21 Dec 2001 13:55:44 -0500

> design.  The security design is longer-lived than any one CS.

  The point that I wanted to make is that a "move" can't 
really fully be implemented on the client side.

  I don't understand what access right issues would be 
resolved by dropping the "move". If I recall correctly the 
discussion started when Steve ask: "Do people have an issue 
with calenders possibly becoming more restrictive after 
a move?"

  Well if we drop the "move" command saying that most
of the functionality could be achieved by a "search", 
"create" and "delete". What are we gaining? 

  If a CUA uses a simple "search" and forward result to 
"create" method, then we are in the same situation, but we 
loose efficiency and open the door to concurrency problems.

  If it is possible for a CUA to implement a move that
satisfies some access right requirements (what ever they 
may be), then what are we loosing by keeping the "move"
command? Couldn't the access right settings be adjusted 
in the same manner by the CUA.

--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Dec 2001 13:10:55 -0700

> really fully be implemented on the client side.

Nor on the server side.

> with calenders possibly becoming more restrictive after

The issues resolved (for later debate and resolution) are:

	What if the parent VCAR sets are not compatible? ...

		What if the UPN's in you GRANTs have DENY in the 
		new parent. You now have bogus VCARS that do
		nothing.

		What if the new parent deny's you access that were
		the bases of the old VCARs? Now most of your
		VCARs are bogus.

		What if the new parent GRANTS all to everyone?
		And you did not know it?

		...

> "create" and "delete". What are we gaining?

(1) CAP out the door faster.
(2) More time to figure out MOVE which can be added later.

> loose efficiency and open the door to concurrency problems.

No - now the CU/CUA can resolve VCAR issues. We can use
that usre experiance to learn what (or if) we can do move
automaticly by the CS.

For now (1) DENY everyone but owner.
	(2) Load calenndar to CUA.
	(3) CUA/CU updates any VCAR issues.
	(4) CUA/CU can decide what to do with outstanding iTIP objects.
	(4) Save calendar to new location.
	(5) delete old calendar.

> command?

Busted VCARs.

> Couldn't the access right settings be adjusted

(CS?)

CUA - Yes. (did you mean CS - No - not withouot user input).

---

From: Patrice Lapierre <[email-masked]>
Date: Fri, 21 Dec 2001 17:33:11 -0500

>                 new parent. You now have bogus VCARS that do

  I don't think so, from CAP section 2.4.2:

        "The access for a particular UPN is the union of
        "all grants for that UPN minus the union of its denies."

>                 What if the new parent GRANTS all to everyone?

  "did not know it?" that is a poor excuse. The only thing a 
protocol can do is to provide the mean to obtain the information
and the "search" command does.

> > What are we gaining?
  
  I still don't see the problems. However if the consensus is to 
wait, then could the first version of CAP supports the "move" 
command for some components (e.g., VEVENT, VTOTO), but prevent 
moving VAGENDA (and VCAR?).

  If we do so a new capability should be added to list
the types of the component that may be moved.  

--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Dec 2001 17:37:22 -0700

>   I don't think so, from CAP section 2.4.2:

Not the same topic. That refers on how to determine the
results of a calendars VCAR set. It does not declare that two
or more calendars will have the same VCARS or that they
are compatable.

> and the "search" command does.

Exactly! That is why the CUA and CU MUST make the decissions.
And the only way the CU can know that is if your CUA did the work, which
is my point. Only the CU will know if that is an issue, and only
after the CUA has loaded the new parent VCAR list, and after it has
loaded the old calerndar VCARS - then the user can know
if they are going to care about VCAR changes.

I just don't see any way to automate this knowladge into the CS (yet).

> the types of the component that may be moved.

YES!! Great idea.