Subject: RE: CAP Draft 6 comments

From: "John Stracke" <[email-masked]>
Date: Wed, 12 Dec 2001 15:47:07 -0500

>Once you have moved an object you could set new VCARs to make it be less
>restrictive.

True.

>The alternatives that I can think of are:
>
>1) Don't carry any of the inherited VCARS during a move. The resultant
>behavior would be a result of the explicity VCARs and the inherited VCARs
>from the new location.

This is what I would consider most sensible.  It's the behavior users will 
expect from their CUAs (if I move things into my public calendar, they 
become public), and we should make it simple for CUAs to provide the 
expected behavior; and it's easier to implement in the CS (no need to 
rework the VCARs when you move something).

I do realize that you could accidentally open up extra permissions this 
way; but I think the right place to prevent that is in the UI, not the 
protocol; embedding that carefulness into the protocol makes it difficult 
to build UIs that do the risky thing when it's appropriate.  By analogy, 
would you expect the unlink() system call (deletes a file) to prompt the 
user for confirmation? No.  Instead, unlink() does what you tell it to, 
and the rm command prompts for confirmation (sometimes).

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|Please do not look into laser with remaining eyeball.  |
\=======================================================/

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Dec 2001 15:22:02 -0700

> rework the VCARs when you move something).

I strongly agree. But can it work?

> and the rm command prompts for confirmation (sometimes).

Yes, but if I move a file from one location to another on any OS,
it does not allow someone to see some of the PRIVATE data insie the
file just because the grandparent directory allowed it, and my
old one did not.

I agree we want this feature. I am not sure we know how to do it.
What would the UI/CU be faced with. For a huge calendar with thousands
of entries, do you want a message that says:

   You moved the calendar, so please pick one of the
   following two choices on how to handle the move:

   (1)  Thousands of of pop-ups saying 'for this entry - what
	do you want this one to be GRANT/DENU . - because it
	the old VCAR set is so much different than the new
	VCAR set (well maybe because - we can't tell as the
	move takes place on the CS).

    or

    (2) Stale cookies - all of the work you did over the last
	few years to set things up the way you wanted or needed
	are gone. Please go through the thousands of object  and
	fix them  - again.

The more we talk, the more I am sure the CUA has to load the
calendar then make a new one - with as you say - the CUA making 
the choices.  I don't think we have solved the problem of
transferring the CU's reason to the CS so the CS can decide
what to do.