Access Control Requirements

[Andy Turk <andy@xxxxxxxxxx>]

If we want the standard to succeed as a basis for interoperability between
existing C&S products, then we will definitely need a standard access
control model. Ignoring access control would lead to a spec where anyone
might see everything in your calendar, or conversely, nobody (except for
those who use the same scheduling product) might be able to see anything.
Neither extreme would go very far to solve the interoperability problem for
customers.

I think we could save ourselves some time by trying to nail down some
requirements before attempting to choose between alternative feature sets.
Here are a couple of suggestions for requirements that our standard should
satisfy.

Requirement #1 Calendar Access Model
Current products seem to offer two different types of access control:
event level (e.g., "private" and "confidential") and calendar level (e.g.,
"view only" and "modify"). Of the two, I think that a standard calendar
access model is a *must* for interoperability. Event level control will be
important to some users, but probably not everyone. We might be able to
live without it.

Requirement #2 Server-side Control
vCalendar (Frank, I'm only picking on your spec because it was well
written :-), lets  you specify an event as being "PRIVATE" but leaves the 
interpretation of what that means up to the software that parses the 
representation. This means that I could download "Bubba's Freeware Calendar" 
which ignores event level access control and see who's having lunch with an 
attractive co-worker. To prevent problems like this, access control should be 
enforced on the server side (i.e., not the client side). 

Thoughts, comments?

Andy Turk
Sarrus Software, Inc.
andy@sarrus.com