Subject: Re: Proposed removal of hierarchy from CAP

From: [email-masked]
Date: Fri, 28 Dec 2001 12:03:01 -0500

Steve replied on 12/27/2001 06:01:12 PM:
>                                                          Nonetheless, I
> think it is a wise move to not have the calid reflect the hierarchy or
> anything else. It is simply an identifier which should not be 
overloaded.

I agree that it was better NOT to overload CalID and that linkages like we 
are really talking about should be done via more appro means rather than 
restricting the CalID.

>         Bruce, do you have any issues with keeping hierarchy with the 
proviso
> that we make it clear that access control and hierarchy are disjoint and
> unrelated?

I have no qualms about removing hierarhical calendars as defined (for VCAR use only really).  I just dont 
want it them to be redefined in such a way that someone could incorrectly 
assume or infer that hierarchy means that some kind of content roll up (or 
down) is possible.  That would be a step backwards instead of forwards.

> How does this affect decreed vcars?

Not sure.  I dont see how they could be applied to the CS at large but 
given a CalID with NO RelCalID portion, couldnt that be used to 
maniuplate/query the VCARs at the CS level?  Attempting to take any action 
that violates either the decreed VCARs or the expressed ones should result 
in an error as the text of 2.4.2.2 says.  The only thing I didnt see was a 
distinction between "CS level" errors from decreed VCARs and "calendar 
level" errors from expressed VCARs.

The design does get simpler since the CS only has to worry about 2 'sets' 
of VCARs to apply instead of evaluating a hierarchy (and a set at the CS 
level) of VCARs...

Bruce
PS: Content roll down is simply the concept that "My companys calendar 
(ie: Holidays)  content could be inherited by my calendar" (being a 
'child' of it as in Dougs League/Division/Team hiearchy).  Its also not 
restricted to 1 level (ie: Company -> Site -> Organization -> Me ).  Im 
NOT proposing we add this to CAP, Im just pointing out that roll up is not 
the only usable direction in town...
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Dec 2001 14:35:41 -0700

[email-masked] wrote:
>
> >         Bruce, do you have any issues with keeping hierarchy with
> the proviso
> I have no qualms about removing hierarhical calendars as defined (for
> VCAR use only really).  I just dont want it them to be redefined in
> such a way that someone could incorrectly assume or infer that
> hierarchy means that some kind of content roll up (or down) is
> possible.  That would be a step backwards instead of forwards.

How about just saying that content roll up is not defined in CAP 1.0.

> maniuplate/query the VCARs at the CS level?  Attempting to take any
> action that violates either the decreed VCARs or the expressed ones
> should result in an error as the text of 2.4.2.2 says.  The only thing
> I didnt see was a distinction between "CS level" errors from decreed
> VCARs and "calendar level" errors from expressed VCARs.

It could be a pain. If I send you a huge VCAR, and only one
small part of it can not be done because of an implementation or site
policy - how could I say that? I do not think we have to:

 Time-1 (By CUA-1):

	BEGIN:VCAR
	GRANT: <lots of stuff>
	END:VQUERY

 Time-2 (By CUA-2):

	BEGIN:VCAR
	GRANT: <lots of stuff>
	DENY: <lots of stuff>
	END:VQUERY

 Time-3 (CUA-1):

	The CUA-1 performs an operation and it fails because
	if the VCAR set by CUA-2 or by a decreed VCAR?

Given:
	CAP does not guarantee that VCARs will not change over time.
	CAP has no record keeping of who or when they changed.

Will at CUA-1 at time-3 know if it is a result if CUA-2, or
by administrative configuration done outside of CAP (A decreed VCAR).
No - And it can not care.

The only thing a CUA can do is get ALL of the VCARs for the TARGET
and look. With the limitation that the authenticated UPN might
not be able to get all of them, or get any of them. And that leaves
VCARs as I think they were intended to be used - to control access
from the CS's point of view, not to describe access to any random
CUA or to any random UPN.

So, an operation fails if you can't do 'that'.

So now, what if a CUA sends a new set of VCARs to the CUA and only
one small part of that fails - what happens? 

	(a) Does the entire operation fail?
	(b) Or a partial success return code?
	(c) Or a success return code that ignores the partial failures?

I say (b). The CUA can then perform a VQUERY to find out what
was not done as it can not override decreed VCARs.

Now, what if the CUA sends a non-VCAR component be stored on the CS.
What happens:

	(a) Does the entire operation fail?
	(b) Or a partial success return code?
	(c) Or a success return code that ignores the partial failures?

If (a) how does the CUA know what went wrong in order for the
CUA, CU, OWNER, or administrator to fix it (assuming something is
buggy or busted)?

If (b), there needs to be a way to say what the problem was else
it looks like (c) and behaves like (a as the entire opertationn
was not done.

If (c), things that are important to the CU could be lost. I think
this is unacceptable.

Do we need some kind of structured 'what when wrong' error messages
containing CUA parable content?

> 'child' of it as in Dougs League/Division/Team hiearchy).  Its also
> not restricted to 1 level (ie: Company -> Site -> Organization -> Me
> ).  Im NOT proposing we add this to CAP, Im just pointing out that
> roll up is not the only usable direction in town...

I could make the company calendar a child calenar link (as I proposed)
and then have roll-up only :-)

-Doug