Subject: RE: Access Control deferred?

From: Doug Royer <[email-masked]>
Date: Fri, 8 Jan 1999 11:19:39 -0800 (PST)

> From: "Paul B. Hill" <[email-masked]>
> Subject: RE: Access Control deferred?
> 
> At 03:53 PM 12/15/98 -0800, Lisa Lippert (Dusseault) (Exchange) wrote:
> ...
> >If we leave access control out of CAP, that does not stop implementations
> >from doing access control, e.g. through an administrative interface, and it
> >does not stop implementations from respecting access control settings.  The
> >proposal is that CAP would just avoid saying how to set access control in an
> >interoperable fashion.  
> >
> 
> "e.g. through an administrative interface"
> 
> Ack! I wouldn't want to administer a system where 20,000 users had to go
> through some seperate adminsitrative, and probably non-interoperable,
> interface to change a delegation or a read privilage. I certainly wouldn't
> buy such a system.
> 
> I think there is a lot of work to do on the requirements still.

Other that if ACLs should be in CAP-1, what other issues are do
you feel make up 'a lot' :-)

> Paul

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/People/Doug
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 20 Jan 1999 16:51:22 -0500

Hi Doug,

>you feel make up 'a lot' :-)

Is there any place in the draft that "deferred" means deferred just for
this draft and we're working on the issues? Or does "deferred" always mean
outside the scope of the CAP requirements document?

Section 4.7 states that CAP must specify how a list of designates is
created. I assume that we're all assuming that this will include removing
delegates. But can a delegate be from a separate autonomous domain?

Can CAP be used to add or remove a user to a system? Or do we consider this
to be an administrative operation that is outside of the scope of CAP?
Section 4.2.3 implies that this will not be addressed by CAP since CAP does
not define users. 

Section 4.3 already indicates that CAP will address creation, deletion, and
renaming. Section 4.3.1 specifically rules out copying on a CS or between
CSs. Does anyone have some insight into why copying is explicitly ruled out?

Section 4.3.1 says, "How a group operations on a set of calendars." OK,
there is obviously a typo but I can't tell what was supposed to be implied.
I do know that I have a requirement for group operations of the type "I
want to invite the programmers in the building to the 10:30 meeting on
Thursday." Does section 4.3.1 imply that this type of transaction will have
to broken down into a list of the intended invitees and then CAP will be
used to invite each attendee as a separate CAP request? Section 4.4.3 also
appears to indicate that CAP will not address this issue.

I think anyone that administers a C&S system wants to be able to do group
operations. What protocol will be used to define and manage these groups? 

Will CAP be useful for administrators or users that wish to set policies on
a group of calendars? E.g. Suppose that I am a user that "owns" 20
calendars. Maybe I'm an AO that is responsible for all of the meeting rooms
in a building. Can I set the access control so that all of these calendars
can be searched for free/busy times but meeting descriptions will be
invisible? Or vice versa? What about when a building is going to be closed
for maintenance and I need to modify the operational hours on all meetings
rooms?

Can CAP be used to clean obsolete information from a calendar easily? E.g.
Can I use CAP to delete all information from a calendar older than June
30th, 1997 unless the meeting is a recurring meeting where the recurrence
extends into 1998?

Section 4.6 states, CAP MUST specify "How the CUA authenticates to CS using
SASL". But I don't see any text that specifies that CAP must be a
connection oriented protocol at this time. It seems that specifying SASL in
the requirements document is an over specification and should be addressed
in the protocol document instead.

Section 4.2.3 introduces a graphic which uses a term which is not defined
in any working group document.

The same section states, "CAP does not define users. CAP does not define
any default or implied relationship between a user and a calendar. Users,
via a CUA, authenticate themselves to a CS to access information. All
access is subject to access control."

All access is subject to access control but access control issues are
deferred. Hmm, I'd say there's a lot left to do one this one subject alone.

Paul