martin: doc/architecture client_server.sgml, 1.7, 1.8 overview.sgml, 1.5, 1.6 server.sgml, 1.3, 1.4

cvs at intevation.de cvs at intevation.de
Wed Mar 17 10:57:07 CET 2004


Author: martin

Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv19561

Modified Files:
	client_server.sgml overview.sgml server.sgml 
Log Message:
Martin K.: priliminary results from the recovery


Index: client_server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_server.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- client_server.sgml	24 Jul 2003 17:24:18 -0000	1.7
+++ client_server.sgml	17 Mar 2004 09:57:04 -0000	1.8
@@ -4,7 +4,8 @@
 <sect1><title> Protocols </title>
 <para> The protocols were selected with the following criteria in mind:</para>
 <itemizedlist>
-<listitem><para>proper standardization e.g. by the Internet Engineering Task Force (IETF,
+<listitem><para>proper standardization e.g. by the Internet Engineering Task
+Force (IETF,
 http://www.ietf.org)</para></listitem>
 <listitem><para>
 open standard in the sense of the term open source</para></listitem>
@@ -26,12 +27,14 @@
 Layer Security (SMTP over SSL/TLS, IETF RFC 2246) </para></listitem>
 <listitem><para> Internet Message Access Protocol (IMAP, IETF RFC 1730), IMAP 
 over SSL/TLS (IETF RFC 2595) </para></listitem>
-<listitem><para> Post Office Protocol Version 3 (POP3, IETF RFC 1939), POP3 over 
+<listitem><para> Post Office Protocol Version 3 (POP3, IETF RFC 1939), POP3
+over 
 
 SSL/TLS (IETF RFC 2595) </para></listitem>
 <listitem><para> Hyper Text Transfer Protocol (HTTP, IETF RFC 2616), HTTP over 
 SSL/TLS (IETF RFC 2818) </para></listitem>
-<listitem><para> HotSync Protocol (this does not meet some of the above criteria 
+<listitem><para> HotSync Protocol (this does not meet some of the above
+criteria 
 
 but
 seems to be widely accepted and free implementations exist) </para></listitem>
@@ -42,7 +45,8 @@
 <itemizedlist>
 <listitem><para> multi-part MIME email as standardized by the IETF 
 </para></listitem>
-<listitem><para> iCalendar and vCard as standardized by the Internet Mail Consortium 
+<listitem><para> iCalendar and vCard as standardized by the Internet Mail
+Consortium 
 (http://www.imc.org) </para></listitem>
 </itemizedlist>
 </sect1>
@@ -74,7 +78,8 @@
 users to the Cyrus IMAP Daemon via the Local Mail Tranport Protocol (LMTP)
 to their respective IMAP mailboxes, which are implemented in the
 maildir format
-(not traditional mbox style, every email is a regular GNU/Linux text file).</para>
+(not traditional mbox style, every email is a regular GNU/Linux text
+file).</para>
  <para> The emails are then
 further processed by the users client desktop application. Note that Cyrus maps
 the above mentioned
@@ -90,7 +95,8 @@
 and the further processing is done locally on the client.
 For compatibility reasons, plain IMAP and unencrypted POP3 message transfers are
 also supported.</para>
-<para> Note that at this point every SMTP and IMAP capable email Client can access a
+<para> Note that at this point every SMTP and IMAP capable email Client can
+access a
 Kolab server's mailboxes
 and distribute email messages via the Kolab server, provided the server IP
 address, the username
@@ -99,9 +105,11 @@
 
 <sect1><title> Vacation Functionality </title>
 <para>The vacation functionality is configured by the user via a simple 
-webinterface available via HTTPS provided by the Kolab server. The actual vacation
+webinterface available via HTTPS provided by the Kolab server. The actual
+vacation
 functionality is implemented on the server
-using Sieve (IETF RFC 3028). A open source implementation of this scripting language
+using Sieve (IETF RFC 3028). A open source implementation of this scripting
+language
 for the Cyrus IMAP daemon is available.</para>
 <para>
 Note that Sieve's capabilities reach far beyond a simple vacation functionality.
@@ -126,7 +134,8 @@
 <sect1><title> Address Book </title>
 <para>The global address book is stored inside a LDAP directory running on the
 Kolab server,
-driven by OpenLDAP v2 (implementing LDAP protocol version 3). The clients access 
+driven by OpenLDAP v2 (implementing LDAP protocol version 3). The clients
+access 
 
 it by using
 the LDAP v3 protocol. The GUI on the client provides read only access to all 
@@ -134,7 +143,8 @@
 inside the directory.</para>
 <para> The LDAP scheme is designed in order to allow easy
 bidirectional conversion to vCard.</para>
-<para> The need to change someones own address book entry is considered to be rare and
+<para> The need to change someones own address book entry is considered to be
+rare and
 therefor a plain web interface is sufficient. A user can modify his own LDAP
 entry using a HTTPS protected web interface. The look and feel is
 analogous to the public phone book dialog.</para>
@@ -143,10 +153,8 @@
 <sect1><title> Groupware Calendar </title>
 <para>Calendar entries are stored in the users IMAP sub folder "Calendar" 
 (German "Kalender") on the
-Kolab server. Physically they are represented as multi-part MIME emails with the 
-
-information stored
-in iCalendar format encapsulated in a MIME part.
+Kolab server. Physically they are represented as multi-part MIME emails with
+the information stored in iCalendar format encapsulated in a MIME part.
 See the appendix for the exact file format and examples.</para>
 
 <para>Group calendar entries are stored just like personal events in the same 
@@ -157,7 +165,8 @@
 exchanging multi-part MIME
 emails and have to be accepted and therewith put into their
 respective calendar folders by the attendees.
-The individual free-busy lists consist of a compacted subsets of the iCalendar data 
+The individual free-busy lists consist of a compacted subsets of the iCalendar
+data 
 covering a user
 definable time range into the future. They are published to a shared ressource 
 on the Kolab server.
@@ -167,25 +176,100 @@
 follow the iCalendar file format.</para>
 <para>The KDE clients store free-busy lists using WebDAVs and read free-busy
 information via HTTPS on the Kolab server.</para>
-<para>Windows Clients must store their free-busy lists via anonymous FTP on the
-server, for historical
-reasons. For lookup of the free-busy lists, HTTP is used by the Outlook/Bynari
-Clients. In this
-project we look not further into this drawback. Instead, a so-called legacy mode
+<para>Legacy Windows NT and W2K Clients must store their free-busy lists via anonymous FTP on the
+server, for historical reasons. For lookup of the free-busy lists, HTTP is used by the Outlook/Toltec
+Clients. In this project we look not further into this drawback. Instead, a so-called legacy mode
 is provided
 on the Kolab server. Using this compatibility mode the dedicated storage area
 for free-busy lists on the Kolab server
 is also accessible via anonymous FTP (upload own free-busy list) and HTTP
 (retrieving all free-busy lists).
- This is an optional setting that will be disabled by default.</para>
-<para>The logic behind the calendar events and their handling is entirely done 
+ This is an optional setting that will be disabled by default.
+</para>
+<para>
+Current Windows XP systems use secure WEBDAV to upload freebusy lists the very same way as the KDE 
+client. The same functionality can obtained using the Novell Webdrive or other 3rd party software which 
+allows to map a WEBDAV resource to a drive letter with Windows 2000.
+</para>
+<para>
+The KDE client obtains the freebusy lists for all potential participants of a meeting and displays them 
+in a gantt chart. This chart allows for the setting of the preview time e.g. next week, next month or any other 
+period of time. In addition to normal users the gantt chart displays also aggregated rows representing either
+personal or central distribution lists. For the later feature the client must be able to aggregate the individual
+freebusy lists of the individual members. The color representation shall indicate if the period of time is occupied is free 
+for all members, some members of busy for everyone.
+</para>
+<para>
+An analogous gantt chart interface is also implemented on the Kolab server using Apache, PHP and producing plain xhtml. An emphasis 
+is here the ability to print the chart nicely. The Outlook Plugin must provide a mean to access this server based gantt chart by either
+integrating the functionality, embedding the html view from the server or as a last resort call the standard webbrowser with the appropriate URL. 
+</para>
+<para>
+The logic behind the calendar events and their handling is entirely done 
 by the client
 applications. The server mainly acts as a network storage in this 
-regard. An exception to this rule is the dealing with automatic shared ressources
-(rooms, technical equipement, cars, etc.).
+regard.
+</para>
+<para>
+The webclient is extended to be able to act as a full Kolab groupware client and allows to view the freebusy lists of 
+predefined groups in a calendar and in a gantt view. All clients must respect the privacy flag for individual calendar entries.
+It is possible to publish the resulting views on the Kolab server permanently. These views can be generated automatically and the access 
+is controlled via LDAP based access controls. The apache webserver checks the access permissions before granting read-only access using the 
+WEBDAV protocol.
+</para>
+</sect1>
+
+<sect1><title>Automatic rules based accepting of invitations</title>
+<para>
+The server implements based on the webclient a mechanism for automatically accepting invitations to special accounts. These accounts 
+could either represent a group (group account) or a resource (resource account e.g. a room, car, lcd beamer etc.). 
+For the automatic acceptance a list of allowed senders is maintained in the LDAP directory. In case the sender is not in 
+this sender list the request is queued like a normal invitation request and the sender is informed about the fact that his 
+request is pending. In case of automatic acceptance no conflict detection is taking place. If the organizer (sender of the invitation)
+changes the appointment this information is propagated to the automatic account like traditional meeting requests. As a result the
+meeting is also moved in the automatic account. Whenever a change happens to the calendar of the automatic account the corresponding
+freebusy list is regenerated and published.
+</para>
+<para>
+For resource and group accounts it is possble to configure the behaviour in case of a conflict. We only implement the following cases.
+This behaviour is configurable in the LDAP directory.
+<orderedlist>
+<listitem>
+always accept (no conflict detection)
+</listitem>
+<listitem>
+accept if no conflict, reject immediately otherwise
+</listitem>
+</orderedlist>
+
+</para>
+<para>
+The adminstrating access to the automatic account is controlled analogous to all other accounts with access control lists. This means access
+controll list are based on user accounts and group membership. The later allows for flexible handling of changing membership without the 
+need to permanently maintain all individual access permissions in case a user changes.
+</para>
+<para>
+The implementation of the webclient and the automatic handling of invitations is handled in such a way that this web component can but is not required to run on the primary Kolab server. From the point of view of the Kolab server the automatic account is implemented with just another Kolab client. This allows for clean and secure seperation while keeping scalability.
+</para>
+<para>
+An automatic booking of a resource or the publishing of a meeting to a group is simply done by adding the corresponding account to the list of invitations e.g. <Audi.A4 at kolab.erfrakon.de> or <marketing at kolab.erfrakon.de>.
+</para>
+</sect1>
+
+<sect1><title>Extended Freebusy lists</title>
+<para>A server process based on the webclient php code extracts all information from the calendar folder of
+predefined accounts and aggregates them in extended freebusy list on demand. Extended freebusy lists are syntactically equivalent to 
+traditional freebusy list but on one hand aggregate the calendar data of multiple accounts and on the other hand prepend the subject of the individual entries with the username followed with the original subject while honouring the private flag.
+</para>
+<para>
+The individual account must allow the extended freebusy list user (called <extended.freebusy at kolab.erfrakon.de>) access to its calendar folder.
+</para>
+<para>
+The server process generates a html gantt with a row for each individual user and an aggregated row with the summed up freebusy times.
 </para>
 </sect1>
 
+
 <sect1><title> Notes </title>
 <para>Notes are stored on the Kolab server inside the users IMAP sub folder 
 "Notes" (German: "Notizen").
@@ -195,10 +279,12 @@
 </sect1>
 
 <sect1><title> Task Lists </title>
-<para>Task lists are stored on the Kolab server inside the users IMAP sub folder 
+<para>Task lists are stored on the Kolab server inside the users IMAP sub
+folder 
 
 "Tasks" (German: "Aufgaben").
-Physically, they are multi-part MIME emails with the actual task list data being 
+Physically, they are multi-part MIME emails with the actual task list data
+being 
 
 a MIME part and
 following the iCalendar standard (vToDo, IETF RFC 2446).
@@ -212,8 +298,8 @@
 just arranging
 a meeting with the shared resource's assigned IMAP user.
 Two modes of operation are supported:</para>
-<orderedlist>
-<listitem><para> manual mode: a real user monitors a shared resources mailbox in 
+<para> manual mode: a real user monitors a shared resources mailbox
+in 
 
 addition to
 his own mailbox and accepts or declines events on behalf of the shared resource 
@@ -226,10 +312,137 @@
 </orderedlist>
 </sect1>
 
+<sect1><title>Access Control and Multiple Identities</title>
+<para>
+Every user has its own personal account with full administrative priviledges. 
+This means that every user is allowed to manages the access permission of all
+folders belonging to him. The user may use these priviledges to grant different
+ levels of access to other 
+named users or groups. In addition the user may use local distribution lists or 
+central distribution lists instead of plain users as the entities to grant access permissions.
+</para>
+<para>
+<orderedlist>
+Local distribution list
+<listitem><para>A special kind of contact in the contact folder consisting of a concrete 
+list of named users. This feature is already built into Outlook but needs to be implemented 
+in the KDE Kontact client in a compatible manner. Kontact uses references to unique contact entries
+in the contact folders.
+</para></listitem>
+
+Central distribution list
+<listitem><para>
+Kolab maintains central distribution list with GroupOfNames LDAP objects.
+        
+        http://www.alvestrand.no/objectid/2.5.6.9.html
+</para>
+<para>
+groupOfNames OBJECT-CLASS ::= {
+        SUBCLASS OF { top }
+        MUST CONTAIN { commonName | member }
+        MAY CONTAIN { description |
+                organizationName |
+                organizationalUnitName |
+                owner |
+                seeAlso |
+                businessCategory
+        }
+        ID id-oc-groupOfNames
+}
+</para>
+</orderedlist>
+<para>
+The KDE Kolab client gets central distribution list from LDAP and is able to create a local 
+copy in the address book which is then stored in the contacts folder.
+</para>
+<para>
+Access permissions (read, write, ....) for distribution lists are identical to contacts.
+The access control lists (ACLs) are manipulated from the client via the IMAP ACL 
+extensions for both the Windows client and the KDE client.
+</para>
+<para>
+The user interface for manipulating the ACLs shall be available via right mouse button 
+on a folder in the folder view. In addition this user interface must also be accessable via the
+menu and a dialog.
+</para>
+<para>
+When accessing folders of other users the identitiy of the user does <emph>not</emph> change. The 
+client must provide in the GUI a mean to configure the displayed prefix to folders not belonging
+to the current user. Internally the server uses the prefix "user". There are two kind of such folders.
+</para>
+<orderedlist>
+<listitem>Folders of other users with explicit access priviledges granted either to the user or to 
+a group where the user belongs to. Typically this involves folders in secretary/boss situations or small adhoc teams.
+</listitem>
+<listitem>Shared folders not belonging to any specific user with explicit access priviledges granted either to the user or to 
+a group where the user belongs to. These global shared folders get typically administered from the maintainers and administrators of the server and serve a larger group of people for an extended period of time.
+</listitem>
+</orderedlist>
+</para>
+<para>
+When working with any folder the default identity for sending messages (e.g. email, calendar invitations etc.) 
+is the real. In addition the user has the choice of graphically choosing the effective 
+identity before finally sending the message via SMTP to the server. 
+</para>
+<para>
+The KDE Kontact client already implements this functionality for email messages and is extended to provide the same functionality 
+for all other activities like invitations, accepting meetings, Task etc.
+</para>
+<para>
+For groupware folders (calendars, contacts, tasks and notes) this has to be 
+implemented correctly in addition to the ability to handle an arbitray number 
+of groupware folders.
+</para>
+<para>
+The Kolab client knows about its standard folders for each identiry for the groupware functionality. This is required in order 
+to allow the client to know where to store accepted invitation, tasks notes or contacts which it got via email and also in case 
+a user has multiple personal calendar folders etc. 
+</para>
+<para>
+The published freebusy list is generated by the client from the standard calendar folder only. Other calendars do not affect the personal
+freebusy list.
+</para>
+<para>
+Visual merging of calendars e.g. of the personal calendar and a group calendar is intentially not provided.
+</para>
+<para>
+When granting access to a subfolder it is the responsibility of the user to allow sufficient permissions for the parent folders
+so that the subfolder is indeed accessable to the other user of group. This is analogous to traditional unix filesystem permissions.
+</para>
+<para>
+Outlook 2002 already knows about multiple accounts. Providing the required 
+functionality for emails is handled via the selection 
+of the account before sending the message. Using multiple accounts for 
+invitations is possible though awkward with Outlook. The later is required
+ if the secretary does not want to 
+become the organizer of a the meeting she is organizing on behalf of the boss.
+</para>
+<para>
+The Outlook Plugin could be extended to provide a besser user interface for this szenario. 
+In Kontact this functionality is provided analogous to choosing the sender identity 
+when sending email. The client must make sure that not only the SMTP sender address is adapted but 
+also the correct content is generated.
+</para>
+<para>
+An extension to the traditionl SMTP message handling is the configurable Kolab feature to be able to verify the 
+SMTP sending address of the sender against a whitelist. This whitelist is looked up
+in the LDAP directory for every sending request. The email address the user used to authenticate itself
+with the MTA (Postfix) ist an implicit entry in this whitelist. The MTA falls back to rewrite the sender address to this
+default address. This address is the afterwards like all sender addresses subejct to LDAP based canonification 
+(e.g. konold at erfrakon.de is rewritten to martin.konold at erfrakon.de).
+</para>
+<para>
+Tassilo: Welche Objektklasse?
+</para>
+<para>
+
+
+
 <sect1><title> Remarks </title>
 <para>The support for message receive confirmations and attaching business
 cards is a matter of the end to end communication between the clients.</para>
-<para> The print services and the Palm OS (HotSync) Synchronization depend fully on the
+<para> The print services and the Palm OS (HotSync) Synchronization depend fully
+on the
 client installation and as such are not related to the client server
 communication.
 </para>

Index: overview.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/overview.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- overview.sgml	24 Jul 2003 17:24:18 -0000	1.5
+++ overview.sgml	17 Mar 2004 09:57:04 -0000	1.6
@@ -2,61 +2,73 @@
 
 <para>This highly scalable and secure solution is strictly based on a 
 client/server architecture.The server part of the groupware solution, herein 
-referred to as "Kolab Server " runs on GNU/Linux,namely on a current 
-distribution out of Debian, Red Hat or SuSE. We minimized the usage of Linux 
-distributiondependencies in order to gain maximal portability. In order to be 
-able to apply readily availablesecurity updates in a timely manner employment of 
-a well-maintained GNU/Linux distribution like theabove mentioned seems 
+referred to as "Kolab Server" runs on GNU/Linux, namely on a current 
+distribution out of Debian, Red Hat or SuSE in addition to FreeBSD.
+We minimized the usage of Linux 
+distribution dependencies in order to gain maximal portability. In order to be 
+able to apply readily available security updates in a timely manner employment of 
+a well-maintained GNU/Linux distribution like the above mentioned seems 
 desirable. The goal is that standard security updates as provided by 
 thesevendors can be installed without affecting the Kolab server 
 functionality.</para>
 <para>
 I is not the scope of this architecuture to integrate with the underlaying
-operating system in such a way that the administration of the os is done with
-it.
+operating system in such a way that the administration of the operating system 
+is done with it.
 </para>
-<para> The free software groupware client application will be developed 
-as a native KDE 3 application.Microsoft Windows NT4 based clients access the 
-Kolab groupware server usingMicrosoft Outlook 2000 with the Bynari Insight 
-Connector Plugin 1.09 installed (reference platform).A high-level description of 
-the complete free software groupware solution seen from the userspoint of view 
+<para> The free software groupware client application is developed 
+as a native KDE 3 application. Microsoft Windows XP based clients access the 
+Kolab groupware server using Microsoft Outlook 2002 with the Toltec Connector
+Plugin installed (reference platform). A high-level description of 
+the complete free software groupware solution seen from the user spoint of view 
 follows. The list was created with existing proprietary groupware products in 
-mind,namely Microsoft Exchange Server with Outlook 2000 
-clients on WindowsNT.</para>
+mind, namely Microsoft Exchange Server with Outlook 2002 
+clients on Windows NT.</para>
 
-<sect1><title>  Email Functionality </title>
+<sect1><title>Email Functionality </title>
 <para>The common 
-internet email functionality is provided:<itemizedlist><listitem><para> sending 
+internet email functionality is provided:
+<itemizedlist>
+<listitem><para> sending 
 email via SMTP over TLS and receive it via IMAP over TLS (preferably) or plain 
 SMTP andIMAP (alternatively for backward compatibility 
-reasons)</para></listitem><listitem><para> support for strong cryptography for 
+reasons)</para></listitem>
+<listitem><para> support for strong cryptography for 
 email bodies and attachments in addition to the securityfeatures provided by the 
 transmission protocol  (as can be found in the former project 
 "Ägypten")</para></listitem>
 <listitem><para> optional support of message receive 
 confirmations (the user gets prompted for an 
-acknowledgment)</para></listitem><listitem><para> adding priorities to emails 
-(importance header)</para></listitem><listitem><para> vacation message 
-functionality (via web interface)</para></listitem><listitem><para> receiving 
+acknowledgment)</para></listitem>
+<listitem><para> adding priorities to emails 
+(importance header)</para></listitem>
+<listitem><para> vacation message 
+functionality (via web interface)</para>
+</listitem><listitem><para> receiving 
 and sending business cards along with 
-email</para></listitem></itemizedlist><para>Every standard-conformant mail user 
+email</para></listitem>
+</itemizedlist>
+<para>Every standard-conformant mail user 
 agent (MUA) and web browser can be used to access the Kolab server for this 
-functionality.</para></sect1>
+functionality.</para>
+</sect1>
 
 <sect1><title>  Contacts </title>
 <para>The client 
 application maintains a private address book ("Contacts", German: 
-"Kontakte").Note that this is very different from a global address book. A users 
-private address bookis stored on the Kolab server. A bidirectional vCard 
-interface is provided. In consequence,vCards received as email attachments can 
-be easily added to a users contacts.</para></sect1><sect1><title> Address Book 
+"Kontakte"). Note that this is very different from a global address book. A users 
+private address book is stored on the Kolab server. A bidirectional vCard 
+interface is provided. In consequence, vCards received as email attachments can 
+be easily added to a users contacts.</para></sect1>
+<sect1><title> Address Book 
 </title><para>A global shared address book is available independently from the 
-above mentioned contacts.Address book entries are maintained inside a LDAP 
+above mentioned contacts. Address book entries are maintained inside a LDAP 
 directory on the Kolab server and can be exported to iCalendar format. 
-The necessary 
-conversion is done by the groupware client application.</para><para> A user can 
+The necessary conversion is done by the groupware client application.</para>
+<para> A user can 
 change his personal contact information on the Kolab server by using a web 
-interface.</para></sect1>
+interface.</para>
+</sect1>
 
 <sect1><title> Calendar Entries </title>
 <para>A user can have private calendar events. Although these events are visible 

Index: server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/server.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- server.sgml	20 Feb 2003 15:15:18 -0000	1.3
+++ server.sgml	17 Mar 2004 09:57:04 -0000	1.4
@@ -196,8 +196,169 @@
 to be expected. Putting the load on the clients basically means that the total processing power is
 increased with the number of clients.</para>
 <para>The design principle for employing server side scripting in scalable
-solutions is: "avoid ressource intensive server operations - smart clients scale better than smart servers"</para>
+solutions is: "avoid ressource intensive server operations - smart clients scale better than smart servers"
+</para>
+</sect2>
+
+<sect2><title>Access Control Lists</title>
+<para>Access Permissions are handled on <emph>folder</emph> level not on
+a message level. The
+user shall be able to query the GUI about access permissions of every
+folder via RMB menu (menue reachable via clicking right mouse button).
+The user is able to manipulate the permissions of his folders using all Kolab 
+clients including the webclient.
+</para>
+
+<orderedlist>On the server side we have to implement multiple things:
+<listitem>
+Provide an API and usage documentation for the access permissions (See
+definitions below for NONE, READ, APPEND, WRITE and ALL)
+</listitem>
+<listitem>
+Provide a webgui for watching/manipulating access permissions for the
+user
+</listitem>
+<listitem>
+Provide a webgui for watching/manipulating access permissions for the
+maintainers/administrators
+</listitem>
+</orderedlist>
+
+<para>
+API for access permissions is derived from the cyrus stuff.
+</para>
+
+<orderedlist>The basic ACLs are
+<listitem>
+l    Lookup (visible to LIST/LSUB/UNSEEN)
+</listitem>
+<listitem>
+r    Read (SELECT, CHECK, FETCH, PARTIAL, SEARCH, COPY source)
+</listitem>
+<listitem>
+s    Seen (STORE \SEEN)
+</listitem>
+<listitem>
+w    Write flags other than \SEEN and \DELETED
+</listitem>
+<listitem>
+i    Insert (APPEND, COPY destination)
+</listitem>
+<listitem>
+c    Create (subfolders)
+</listitem>
+<listitem>
+d    Delete (STORE \DELETED, EXPUNGE)
+</listitem>
+<listitem>
+a    Administer (SETACL)
+</listitem>
+<orderedlist>
+
+<para> These Cyrus access permission are combined in different ways in order to obtain Kolab access permissions. The user shall neither
+directly see nor manipulate the Cyrus access permissions.
+</para>
+
+<orderedlist>We define therefore
+<listitem>
+NONE    -
+</listitem>
+<listitem>
+READ    lrs
+</listitem>
+<listitem>
+APPEND  lrsi
+</listitem>
+<listitem>
+WRITE   lrsiwcd
+</listitem>
+<listitem>
+ALL     lrsiwcda
+</listitem>
+<orderedlist>
+
+<para>Only these five high level Kolab access control permissions shall be available
+via the Kolab clients.
+</para>
+
+<para>
+In the imapd.conf we specify the admins/maintainers users which have
+l and a access permissions implicetly on every folder.
+</para>
+
+<para>
+In the configuration file imapd.conf we specify the default access control list for public folders. This configuration option is stored 
+and maintained as always in the LDAP directory.
+</para>
+<para>
+Normal folders inherit the access control list from its parent folder.
+</para>
+
+<para>
+For special purpose (e.g. bulletin boards) we use the following access control list
+</para>
+<para>
+READ ANON lr
+</para>
+<para>
+The specified user/group can see the folder and can read it, but the
+server does not preserve the "Seen" and "Recent" flags. This set of rights
+is primarily useful for anonymous IMAP and public shared folders.
+</para>
+<para>
+READ HIDDEN rs
+</para>
+<para>
+The specified user/group can read the mailbox and the server preserves the
+"Seen" and "Recent" flags, but the mailbox is not visible to the user
+through the various mailbox listing commands. The user/group must know the
+name of the mailbox to be able to access it. This set of rights is useful for non public shared folders.
+</para>
+<para>
+Basically the user is using the Kolab client using his primary 
+identity. Based on
+this identity he gains access to folders owned by other users or the
+system (shared folders). There is no change of identity when accessing
+foreign folders. The server checks for access via the user identity /
+credentials provided when connecting to the Cyrus imap server.
+</para>
+<para>
+When listing the available folders from the server in the imap subscription dialog
+the user sees all folders with the lookup permission in the folder tree.
+</para>
+<para>
+Whenever sending a message (e.g. an email) via SMTP the user is asked
+which sender indentity is to be used comparable to the current KDE 3.2.1 
+KMail implementation. There shall be no popups or modal dialogs in the way when doing so.
+The decision has finally to be made immediately before message is beeing send.
+</para>
+<para>
+When editing/creating (IMAP append) groupware messages then the identitiy
+within the message must be set accordingly in order to be useful. (e.g.
+organizer of an event)
+</para>
+<para>
+The GUI of the Kolab client shall be aware of the ACLs and behave
+accordingly. E.g. dont allow saving of a message in a dIMAP folder if
+write permissions are lacking. This is required in order to prevent
+problems when used in disconnected mode. The Kolab client has to keep the
+acl information uptodate in its local cache in order to make delayed 
+access permission problems unlikely.
+</para>
+<para>
+Nevertheless the Kolab client must be able to handle and resolve a potential a potential 
+lock (e.g. permission to write to a folder with pending new messages got lost recently). 
+The Kolab client shall continue to synchronize as much as possible, warn the user via a dialog about 
+the fact that some folder could not be written to and preserve the messages. The conflict resolution e.g.
+mving or deleting the conflicting messages is up to the manual procedure by the user.
+</para>
+<para>Kolab only ever uses positive access permissions. This means that the Kolab access permissions only 
+control the access via allow parameters for users and groups. There is no concept of negative access permissions as
+well known from Apache like deny statements.
+</para>
+
 </sect2>
+
 </sect1>
 
 <sect1><title> ProFTP Daemon </title>
@@ -208,6 +369,7 @@
 <para>Its only functionality on the Kolab server is the legacy mode to enable Windows clients to publish
 their free-busy lists via anonymous FTP on the server. If only KDE clients connect, the FTP
 functionality is not needed.</para>
+
 <para>FTP is deactivated by default, for security reasons.</para>
 </sect1>
 





More information about the commits mailing list