Private groupware objects

[Bernhard Reiter]

The problem of the "access" choice in  Outlook's GUI still needs to be solved.

Let me try to summarize what we have.
I have spend some time with Martin on the phone 
going through the various possibilities.

There apparently is agreement that security must be enforced
on server side and that we do not get far with encryption.

Given the technical differences, I believe it will be quite hard
to make Outlook accept different calendar folders fully
in the near future. So this road will not lead to a solution soon.

This leaves two principle approaches:
a) Joon's proposal of extending the IMAP protocol.
     
b) The principal idea of using  an addition folder and merging
    the results for Outlook. Originally proposed by Martin, 
    but with some variations by others.

Both would solve the problem on the server.

a) Enchance IMAP Protocol: Will create a lot of work in the area
  of the IMAP standard and on the implementation side of Cyrus.
  Advantage: It is less work on the clients.

b) More work for the clients.
  The best suggestion here I have seen would be to :

  Use a completely second namespace for a private tree that is modelled after
  the regular tree. It has the advantage that the ACL for the owner could
  later be enforced by the serverfor this namespace.
  Also the KDE client could display these extra folders 
  just like regular folders, while only Outlook would need to merge it.

Joon, Johannes: Do you think b) would be technically feasable for you?

My next question would be:
Is this something for a Kolab Format/Concept 2.1 or 2.2?
I would say yes, because it is a bit of development.

Bernhard