Subject: Re: CAP Draft 6 comments

From: "John Stracke" <[email-masked]>
Date: Wed, 12 Dec 2001 18:32:36 -0500

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

Er...it might.  On Unix, if you have a file in a directory where I do not 
have permissions, I cannot list the directory, and I cannot read or write 
the file even if the file itself says I have permissions to do so.  If you 
then move that file into a directory where I *do* have execute 
permissions, then I can read the file if the file says I can.

I'm not convinced that this is too complex to solve right now.  However, I 
am convinced that putting it off is safe (safer than getting it wrong, 
anyway :-), so maybe that's the right thing to do.

/=================================================================\
|John Stracke                   |Principal Engineer               |
[email-masked]  |Incentive Systems, Inc.          |
|http://www.incentivesystems.com|My opinions are my own.          |
|=================================================================|
|For the life of me, I've never understood why people dismiss the |
|importance of "semantics" in communication. After all, if        |
|semantics had no purpleness, you'd slitheringly go bold at by-sit|
|it I'm climbing. -- Tangwystyl                                   |
\=================================================================/

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 20 Dec 2001 16:38:11 -0500

> permissions, then I can read the file if the file says I can.

Exactly : "if the file says I can".

We agreed about a month ago to allow VCARs in all (or
most) components.  So let's take advantage of it.

If a user is concerned about a particular VEVENT's
access rights, he will add a VCAR within that VEVENT.
When that VEVENT will be moved from one calendar to
another the VCAR will remain with the VEVENT.

When moving a VEVENT (or a group of VEVENT) from one
calendar to another, a CUA could propose the calendar
user to duplicate the VCARs that currently apply to
the VEVENT within the VEVENT itself before moving it.

Doesn't that address the concern?

> anyway :-), so maybe that's the right thing to do.

The move command is too important to be left out.
If more work is required in the VCAR, let's do it
now, instead of dropping basic functionnality such
as moving a component.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Dec 2001 12:45:29 -0700

> most) components.  So let's take advantage of it.

Several of us agreed. But that does not mean it will work :-)
There may be issues.

> another the VCAR will remain with the VEVENT.

We have not talked about this yet. For example, what if
you export a VEVENT with a GRANT for UPN=doug, but you
mean [email-masked] and not [email-masked].

We need to think about the issues here.

> Doesn't that address the concern?

Do you really want ALL VCARS in each object? That is what
I think you just said.

> now, instead of dropping basic functionnality such

Too important? Is it worth holding up CAP for 6 months to 12 months
when we can add it on later?

Just wanting it does not solve the problems. I still say
only the CU/CUA knows, load up the entire calendar, copy it,
delete the old. Then the CU/CUA can address access issues.

-Doug