Re: access control

["William P. Spencer" <bill@xxxxxxxxxxxxxx>]

You are right on target Jay.

Event "links" are really just a special type of event, so should just be
part of the event object.  If there is a related group of events then 
they should be related by a common category specifier. 

And the comments on the access control are correct, too.  The spec needs 
to specify some levels of access control which indicate what services 
are allowed/available to the user agent from the server.  It's not the 
UA that is imposing the access control, it's the server, based on 
policies set by the individuals who own the calendar, or server.

Reading Jay's note brought up an interesting point in my mind, which is:
It may be very tempting to create a Level I spec, and defer other
difficult, or otherwise not well understood, operations to a Level II
spec.  In general, I'm not in favor of this because it's too easy to brush
off critical topics because they are hard, and thereby miss some critical
issue which will be harder to correct later.  This is not to say we
shouldn't have a Level II spec, but if we defer something to it, it should
only be after careful study.  My first glance at Jay's message caused me
to mis-read it, and I thought he was somehow deferring the issue of free
time searches.  However, a closer read made me realize that the opposite
was the case.  As Jay points out, the need for free time searches, and the
equal need to limit free time searches requires linking it to access
permissions.  We need both access permissions, and capability for free-time 
search in our spec.

Jay Batson wrote:

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


Bill Spencer
<bill@p2software.com>