[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: forced VCAR (was: revised security section)
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
>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.