Subject: Re: FW: Access Control deferred?

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

> From: "Mark Poepping" <[email-masked]>
> 
> I confess only recent tracking of this activity, but comments
> about the ACL issue prompt me to wonder what exactly we expect
> to accomplish by standardizing CAP without ACL support..
> 
> Who among the vendors has plans to ship an administrative client
> (separate from your cal product) to handle ACL's (presumably to
> a non-native server)?

It does not have to be separate or together. A PDA for example
will not do ACL's. It will just see the results of permission denied.

> It seems to me that cal, more so than http or even imap, *must*
> specify a way to manage access to objects from the start.  The
> information in calendar objects is expected to be shared in more
> ways than either http or imap are generally used today (the
> "groupware" thing).

There was some strong objection to combining CAP-1 and ACLs.
So we thought that we would send them out separately.

I would not object to them being combined. Perhaps the CHAIR can
decide which way its flowing and see if there is a 
general consensus?

-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: Doug Royer <[email-masked]>
Date: Wed, 20 Jan 1999 16:06:46 -0800 (PST)

> Date: Wed, 20 Jan 1999 17:03:45 -0500
> From: "Paul B. Hill" <[email-masked]>
> 
> Hi Doug,
> 
> >As I recall in LA we said that the only administration that would be
> >in CAP was whatever the USER needed plus creating a new calendar for
> >them selves, and deleting a calendar they owned. I also think we
> >said that calendar store (vs calendar) administration would not be
> >in CAP.
> >
> >I think that all other administration was considered not in CAP.
> >
> 
> OK, I think an assitant that is responsible for 20 meeting rooms, some
> audio visual equipment, and is delegate for a couple of mid-level managers
> is not a CS administrator and that CAP needs to accomodate the needs of
> this user. I don't think that the current requirements draft will meet the
> needs of this type of user.

Good input :-)

As you have ideas in this area - would you like to write the CAP section
on administration and accept the responsibility of forming a
general consensus and being the primary owner of this area?

The more that help, the more we get done.

I am swamped as are others. Without help CAP-1 may suffer and
be limited to what we have time to get done. Which currently
does not address this issue.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 20 Jan 1999 16:01:35 -0800 (PST)

> Date: Wed, 20 Jan 1999 16:51:22 -0500
> On the 8th of January you asked:
> >
> >Other that if ACLs should be in CAP-1, what other issues are do
> >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?

Outside of the scope of what we called CAP-1.  In order to make CAP
happen soon we had to trim down the requirements.

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

The idea was that a calendar-user was just a string that would be
compared.

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

The talk was that adding and deleting users can involve much more than
just calendar issues.  On some operating systems this requires
interfaces to the OS and may include some OS policy issues.  So we
punted and skipped this issues (deferred) this in CAP-1.

Some had confused adding and deleting users with adding and deleting
calendars.  Some (me) do not see a 1:1 relationship between the two
issues.  I should be able to assign a user (string) as the calendar
owner - without the OS knowing anything about the user (string).

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

I would think it would be possible for a CUA to read all components
from one calendar and write them to another.  Copy was not seen as a
needed item for CAP-1.

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

The idea was that performing 'group' operations on multiple calendars
implies some kind of transaction locking.  We proposed that
transaction locking not be in CAP-1.

So I think we meant to say that it will be possible to select more
than one calendar to perform an operation onto using the CAP-1
protocol, but you will get multiple replies and one or more calendars
may say "NO" for some named reason.

Unlike a transaction locked model where you are guaranteed that a
group operations succeeded on all calendars or did not happen at all.

Example:

I need a CAR, HOTEL, and FLIGHT so that the date, times, airport
location all agree with each other.  You need a transaction locked
group scheduled operation as you might not want to book a flight if
you can not get a hotel or car.  This is what we were saying would not
be in CAP-1.  RFCs for transaction locking exist (2371 and 2372 I
think are the correct ones).  At a later time a new CALSCH
proposal/RFC showing how to use standard transaction locking in CALSCH
could be released.  This is a big complex issue - why we want to punt
this in CAP-1.

I need JOE, JIM, and SALLY to attend this meeting.  Where one or more
of them may say no.  No transaction operation needed.

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

Yes - I agree and I think that others agree. The confusion here
is that is what was meant was that "transaction" locked group
operations will not be supported in CAP-1.

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

I don't recall that we had this kind of discussion. 

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

I would agree.

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

Again, getting "PERMISSION DENIED" does not imply that CAP-1 knows why.

Access control is a large issue. So if we can specify how CAP will
in some generic way address access control, and we tackle access control
separately and in parallel from CAP-1. I think that CAP-1 will get done.
Otherwise I think that access control will consume much time and
the two issues will be serialized and both will suffer.

-Doug

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 20 Jan 1999 19:33:53 -0500

>general consensus and being the primary owner of this area?

:)

Let's see how many of my other tasks get done before the 26th. That's when
I'll make my decision about attending the NY meeting. I should know if I
can take on another commitment by then.

Thanks for your rapid feedback on my comments. 

Paul