Handling of private/confidential groupware objects

[Helge Hess]

On 30. Nov 2005, at 05:25 Uhr, Martin Konold wrote:
> The GUI of both Outlook and Kontact offer the possibility to make some
> groupware objects private/confidential.

I think you mix up two things (quite a common misconception):
a) sensitivity (private / confidential / public [/ top secret /...])
b) access control


a) has nothing to do with b), its like the red "top secret" or  
"confidential" print on a file.
The intention is to make the information consumer aware of the  
sensitivity of the data. Eg a secretary won't open a file marked "top  
secret" but rather pass it on to her general (but she stil has access).
Or to give another anology: you might tell your friend your personal  
income but explicitly tag the information as "private". So he will  
know that he must not tell other people or get kicked.

Access control is different. It actually prevents someone from  
getting hands on the file. This is different from a) because users of  
a) are allowed to deal with the file. The sensitivity is just to make  
them aware of the "privateness" of the information (eg how they are  
supposed to deal with it wrt other persons).
In the Army scenario a secretary won't get near the "red button" w/o  
appropriate credentials. Access control is el mucho stricter.

Summary:
a) informational
b) strict


Now two put it into the technical context of Outlook and Kontact (and  
Evolution/Sunbird).

Kontact(/E/S) "only" supports the iCalendar "class" property which is  
just a). It has nothing to do with actual access permissions. Which  
is somewhat obvious if you consider iCalendar in its original context  
- iMIP(/iTIP). iMIP has no concept of access control but mails can  
contain markers to make the recipient aware of the sensitivity of the  
information.

Outlook supports both a) and b). a) is represented by the  
PR_SENSITIVITY MAPI property while b) is implemented by a different  
GUID named boolean property.

Summary:  If you want to implement it properly, you need to Keep 'Em  
Separated.

Summary2: you can't do that with IMAP4 because you lack per-message  
access control.
   calendar.private is insufficient. You would at _least_ need to have
   calendar.$userid$ since private as per b) belongs to a certain  
user [unlike a)]

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org