Subject: Re: cc: re: Further agreement with Alex

From: "Doug Royer [N6AAW]" <[email-masked]>
Date: Tue, 6 Oct 1998 18:32:51 -0700 (PDT)

> >General thoughts from them were:
> >1. Allowing free-time search should be an open process
> 
> ***** Comment from Ralph Patterson on 10/06/1998  at 4:34 p CST *****
> It creates a basic security concern expressed in the beginning of this 
> process, namely, even free busy schedules could be used to ascertain 
> private information. e.g., by viewing key players, perhaps one that 
> publishes specifics, or uses an unsecured server, others schedules could 
> be deduced. Even free/busy searches need some way to limit access.
> ***** End of comment *****

Agree - it must be configurable by the owner / administrator.

> >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.
> 
> ***** Comment from Ralph Patterson on 10/06/1998  at 4:39 p CST *****
> Doesn't granularity to the user level accomplish this? I would assume 
> that since many current scheduling packages allow this level of control, 
> users will be hesitant to give up that feature. 
> ***** End of comment *****

It needs more control that this. What if the SUMMARY, DESCRIPTION, and
ATTENDEE list needs to be limited, but not DTSTART, DTEND/DURATION,
LOCATION or COMMENT. There needs to be property and parameter control.

There are needs in this area. So more access control is needed and
at a finer level of control than the calendar, owner, or component.

> >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.
> 
> ***** Comment from Ralph Patterson on 10/06/1998  at 4:41 p CST *****
> If we can't secure the updating of information, should we just abandon 
> the project? Limiting who can update the calendar will "break" many 
> scheduling packages (mine included). One of the key issues to our user 
> base is the ability for secretaries, supervisors, etc. to add items to 
> others' calendars. I understand your comment to mean this should not be 
> allowable. If that is an accurate characterization, we can't support it. 
> I'm starting to get the impression that the people surveyed were MIS 
> people.
> ***** End of comment *****

A calendar owner / administrator needs the ability to determine a
named list of users that can perform operations on their calendar,
who has access to a particutlar component or properties in a component.

> >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.
> 
> ***** Comment from Ralph Patterson on 10/06/1998  at 4:45 p CST *****
> That would be no access control. Correct? I don't think anyone expects us 
> to get a specification done that would ONLY allow open access. Yet I 
> believe that allowing full access to a calendar should be possible if 
> desired by the owner.
> ***** End of comment *****

I think he agreed with you. This must not occur by decree,
it must occur under the control of the calendar owner / administrator.

---

From: Bob Mahoney <[email-masked]>
Date: Wed, 07 Oct 1998 14:24:33 -0400

It's reassuring to see this level of interest in what is bound to be a hard
problem.  :-)

I think we need to see a rich set of control features, such that access to
all properties are user configurable.  (Maybe just "Most Properties": I'm
not sure there is a real use for knowing a meeting summary, for instance,
if there is no time or date context whatsoever)  

We also need to see reliable authentication of scheduling participants, and
realistic data protection for objects in transit.  While some
users/administrators will choose to diable this protection, the tools must
be present.

-Bob