Subject: Further agreement with Alex

From: Pat Egen <[email-masked]>
Date: Tue, 06 Oct 1998 17:04:40 -0400

I took a few extra days to do a quick survey of random companies that are part
of the SHARE users group.  In talking with 9 companies (totalling over 350,000
email ids) the general concensus is there needs to be security over calendars
that ensures granularity such as many of the group are recommending.

General thoughts from them were:
1. Allowing free-time search should be an open process
2. Control over view needs to be more atomic than at the main organizational
level.  I.e. individuals within not only an organization, but within a
department need to have the capability to control who can/can not see their
calendars.
3. Update capability must be in the control of the individual user and most
companies said only the owner of the calendar entry would have update capability
over the net.  Two  companies (one, a very large organization)stated they would
prefer no updates over the Internet, even from the owner of the calendar.
4. All agreed there should not be a generic open access to calendaring. If there
was, all companies said they would not use Internet Calendaring access.
Geoff Coupe wrote:

> Folks,
>
> I agree strongly with Alex, and would add that this is not just a "vendor
> requirement". I work in a services company, and we already have the
> requirement that we want to expose elements of our calendars to clients on
> an organisational basis. Thus, client A would be able to see appointments
> relating to his/her organisation, client B would be able to see appointments
> relating to his/her organisation, and so on. Internally, all of my
> appointments (apart from those that I have marked personal/private) would be
> visible to my colleagues. The rationale is that this capability is
> demonstrating good customer focus, while providing separation on an
> organisational basis. You can get some good competitive information if you
> have totally free access to calendars!
>
> I can also see that with the enforcement of the new European Data Privacy
> act next month, that this will have some impact on what we are expected to
> do in a business context.
>
> Geoff Coupe
> Shell Services International
>
> -----Original Message-----
> From: Alec Dun (Exchange) <[email-masked]>
> To: 'Doug Royer [N6AAW]' <[email-masked]>; [email-masked]
> <[email-masked]>
> Date: Monday, September 28, 1998 11:35 PM
> Subject: RE: My proposal for CALSCH-ACLs
>
> >Yep.  The propertly level ACL requirement comes from scenarios such as
> >letting some people see when your appointments are, while not exposing what
> >the appointments are about or who you're meeting with.
> >
> >Quite a number or vendors I talked to wanted fine-grained control over what
> >properties could and could not be seen on a per/user basis.
> >
> >Thanks,
> >Alec.
> >
> >-----Original Message-----
> >From: Doug Royer [N6AAW] [mailto:[email-masked]]
> >Sent: Friday, September 18, 1998 4:05 PM
> >To: [email-masked]
> >Subject: Re: My proposal for CALSCH-ACLs
> >
> >
> >
> >> From: "Frank Dawson" <[email-masked]>
> >>
> >> I STRONGLY disagree with the initial CAP draft having ACL control at the
> >> calendar component or property level. This atomic level of ACL is beyond
> >> what we need.
> >
> >There were strong suggestions that ACLs at this level were needed
> >in CAP. I think the issue can be resolved soon by having a well
> >defined set of fallbacks.
> >
> >ACLs over the wire is an administrative issue. There is no
> >reason that all calendar clients would need to know they exist.
> >I do think that it is important to define the ACLs so that client
> >can understand the model and can prepare for operations that
> >will fail with permission denied.
> >
> >A CUA without understanding the ACL model, might:
> >
> >  Expect to have 100% control over the calendar *if* the name of the
> >  calendar is the same as the users authenticated users name.
> >
> >  Another CUA (as described by the fellow from MIT at the LA IETF),
> >  Might know that all calendar entries are never deleteable as
> >  their server must enforce this per some kind of record keeping law.
> >
> >A CUA that understands the ACL model, can then:
> >
> >  Understand that they might get permission denied without knowing
> >  the details of why it happened.
> >
> >  Might implement a (yet undefined) command to find what ACLs the
> >  user has and adjust the CUA at runtime to guide the users operation
> >  of the CUA.
> >
> >I think there MUST be SOME administration in CAP. Not all CUAs will
> >need to implement administration commands. I throw ACLs into
> administration.
> >
> >> If you are serious about a CAP draft by year's end, then we need focus on
> >> defining a CAP spec based on simplified (but useful) set of requirements
> >for
> >> the CUA/Calendar Store interactions. You can't say that you want an
> >initial
> >> draft of a spec by year's end and then step into a complex arena, such as
> >> calendaring and scheduling security, and try to boil the ocean on
> function
> >> enablement.
> >
> >Yes I would like an initial draft by the first of the year.
> >
> >The security issues have been address in other drafts/RFCs that
> >have access control. There really is not anything new. We just
> >have to map the ideas that others have discussed into CALSCH.
> >
> >Calendar store interactions, I will be sending out my proposal
> >on that Tuesday (22nd) or so :-)
> >
> >> You also need to look at accepted practice. The majority of enterprise
> >> calendaring systems out there today have an ACL model that is based on
> >> calendaring capabilities, not calendar structure. As a matter of fact,
> >this
> >> approach of basing "rights" specificity on capability is very client
> >> centric. It provides "rights" that directly map to what the CUA is
> >> providing. For example, a simpler ACL model would be based on rights that
> >> amount to booleans for the following :
> >>
> >>    No Access (provided by FALSE to all of the following rights)
> >>    View Busytime Information
> >>    View Public Events (two more for To-dos and Journal entries)
> >>    View Private Events (two more for To-dos and Journal entries)
> >>    View Confidential Events (two more for To-dos and Journal entries)
> >>    Add Public Events (two more for To-dos and Journal entries)
> >>    Add Private Events (two more for To-dos and Journal entries)
> >>    Add Confidential Events (two more for To-dos and Journal entries)
> >>    Change Public Events (two more for To-dos and Journal entries)
> >>    Change Private Events (two more for To-dos and Journal entries)
> >>    Change Confidential Events (two more for To-dos and Journal entries)
> >
> >This is almost the Sun legacy model. However for shared calendars using
> >iCalendar, how would you allow a user to update their PARTSTAT,
> >while at the same time not allowing them to alter the rest of the
> >calendar entry?
> >
> >The ACL model that I have proposed will also work with the model
> >you have above. I made sure of that as Sun has almost same model.
> >
> >> Defining a "rights" component for CAP ACL beyond this is not acceptable
> >for
> >> a near term CAP spec. Something beyond this level of function enablement
> >is
> >> counter to the theme of scheduling the CAP effort to get a draft out by
> >year
> >> end.
> >
> >I don't agree. Even if not all of the ACL model makes it in the draft, I
> >think we need to define ACLs for the reasons I have stated above.
> >
> >> It would be beyond what is provided for in the majority of enterprise
> >> calendaring applications today.  It would also be defining an ACL
> >> infrastructure that may present significant problems mapping into
> whatever
> >> directory and common IETF ACL architecture is defined in the near future.
> >
> >I agree that it does expand the access control model.
> >
> >I *do* think that it is mapable into existing CUAs.
> >
> >As to any common IETF ACL architecture that may be defined in
> >the future. We in the CALSCH-WG should spend the time to make
> >sure that if anyone ever submits such a draft that it allows
> >for CALSCH needs.
> >
> >ACAP (as Chris Newman pointed out) has a generic ACL administrative
> >model. I think it could get a bit verbose. I see no conflict here.
> >And I have already thought through an "ACAP ACL command" to
> >"CALSCH ACL data" mapping that would have to be done if ACAP
> >were used for administration of the iCalendar server.
> >
> >The only thing that I wish ACAP would have done is differentiate
> >between write Vs (append Vs modify). Append Vs modify would have
> >to be done with the use of digit rights (RFC2244 ACAP section 3.5).
> >
> >-Doug
> >-------------------------------------------------------------------
> >[email-masked] http://www.royer.com/dougr.html
> >801 W. El Camino #131 Work:   (650)786-7599
> >Mountain View, CA 94040 Ham Radio: N6AAW, Aviation: PP-ASEL
> >