Re: access control

[Jay Batson <JBATSON@xxxxxxxxxx>]

On 7/26/96 at 12:26PM you said:
>Arathi Balakrishna wrote:
> 
>> 2.It would be nice to have links to other calendar events on  a user's
>> personal calendar.  Has it been given any thought?
>
>You are talking about the concept of event lists.  Event lists are not
>calendars, but simply lists of events typically related in some way e.g.
>Holidays, Company events.  Using event lists the user can bring events
>into her calendar which are not necessarily appointments, but just
>events to be aware of.  Event lists provide a mechanism for people or
>companies to publish lists of their events to the world and allow
>individual users to bring those events into their personal calendars. 
>For example, the SF Giants could publish a list of their baseball
>games.  If a user added this event list to their calendar, the baseball
>game schedule would show up in their calendar and maybe they could
>select specific games to be notified on, but most of the games would
>just be place holders for viewing purposes only.  In the intranet world,
>companies could publish event lists for company events, etc. which would
>show up on all employee personal calendars.
>
>This is a very powerful feature and something we should definitely
>include in our investigation.

A reminder that the process of creating a standards spec is slightly 
different than creating a product.

Products want neat features.  Standards specs want to powerful base 
constructs that products can be built on.

To me, "event lists" are a function that arise out of careful definition 
of an event object containing a type tag.  What happens with the event 
object and its type is up to the product implementer.  If the vendor wants 
to put it on a web page with links, or embed it in a Windows object, it's 
up to the vendor.

As to Arathi's original access control comment, the spec should specify 
coarse access control mechanism, but not policy.

For example, not every company will want to allow free/busy time searches. 
 So providing them should not be required for a product to "meet the spec".
  However, the spec *should* provide a mechanism to allow a program to 
require one level of authentication for free/busy time searches as 
contrasted with the level that allows viewing the contents of a particular 
users' calendar.  The former would be useful for companies who want to 
provide free/busy time searches to "trusted" foreign domains (e.g. trading 
partners) but not to the "general public.  Other administrators / users 
might choose to provide any/all info without authentication.

Anything in the spec that is designed to "inquire" about information 
should permit differing behavior based on authentication level.

As a reference, SSTP provides for this in its authentication mechanism.  
You can authenticate any way you can.  If you've provided "enough" 
authentication to satisfy the inquired system, you get what you've asked 
for.  If not, you get an error code back saying you don't have access to 
this info.

-jb

-----
Jay Batson
ON Technology Corp.
jbatson@on.com
617-692-3591