Re: forced VCAR (was: revised security section)

["Paul B. Hill" <pbh@xxxxxxx>]

Hi Frank,

I can't figure out if we agree or disagree yet. I suspect that we actually 
agree, please read on.

>> IMHO setting an enforceable CS policy fails the test that we have been
>> using, therefore CAP should not address this topic.

>I am probably not certain what you completely mean by "enforcable", but 
Lotus definitely >believes that CS VCAR access policy needs to be an 
initial CAP target for VCAR specification >in Version 1.

OK, "enforceable" was a poor term to use. Maybe "imposed", "decreed", 
"established by edict" are better terms to describe the concept. The idea, 
as I understood it, was that a CS MAY choose to implement and allow 
persistent immutable VCARs, that are configured by the CS Administrator, 
which apply to all calendars on the server. For example a company may 
decide that it wants all calendars on its server(s) to have the Policy 
READBUSYTIMEINFO.

>For example, "GRANT View Public Entries" or "GRANT View Busy Time 
Information" or "GRANT >Create and Update Public Entries" or "DENY Create, 
Update and Delete Entries".

But aren't you talking about the end user performing these operations on 
calendars that they control?

I'm talking about the case where a CS implementation allows the CS admin to 
impose "GRANT READBUSYTIMEINFO" to all calendars. If a user subsequently 
attempts to modify this to  "DENY READBUSYTIMEINFO" on a specific calendar 
an error will be returned to the user.

First, I do not think that all CSes must be required to implement the 
ability to create global immutable VCARs. I think this is a feature that 
each CS vendor should be free to implement or not.

Second, I do not think that the CAP protocol needs to define how the CS 
admin would  communicate with the CS to enact or create a global immutable 
VCAR by decree.

Paul