martin: doc/architecture client_server.sgml,1.10,1.11

cvs at intevation.de cvs at intevation.de
Sun Oct 3 05:34:47 CEST 2004


Author: martin

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

Modified Files:
	client_server.sgml 
Log Message:
Martin K.: Updated calendaring


Index: client_server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_server.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- client_server.sgml	13 Apr 2004 01:56:20 -0000	1.10
+++ client_server.sgml	3 Oct 2004 03:34:45 -0000	1.11
@@ -1,5 +1,5 @@
 <chapter><title> Communication between Client and Server </title>
-<para>A technical description of the communication between KDE clients and the 
+<para>A technical description of the communication between KDE clients and the
 Kolab server follows.</para>
 <sect1><title> Protocols </title>
 <para> The protocols were selected with the following criteria in mind:</para>
@@ -9,7 +9,7 @@
 http://www.ietf.org)</para></listitem>
 <listitem><para>
 open standard in the sense of the term open source</para></listitem>
-<listitem><para> existing open source software implementations must 
+<listitem><para> existing open source software implementations must
 scale very well</para></listitem>
 </itemizedlist>
 <para>In general simplicity is preferred over complexity. The
@@ -19,22 +19,21 @@
 project:</para>
 <itemizedlist>
 <listitem><para> Lightweight Directory Access Protocol Version 3 (LDAP, IETF RFC
-
 2251) </para></listitem>
 <listitem><para> File Transfer Protocol (FTP, IETF RFC 765) </para></listitem>
-<listitem><para> Simple Mail Transfer Protocol (SMTP, IETF RFC 2821), SMTP over 
+<listitem><para> Simple Mail Transfer Protocol (SMTP, IETF RFC 2821), SMTP over
 Secure Socket Layer / Transport
 Layer Security (SMTP over SSL/TLS, IETF RFC 2246) </para></listitem>
-<listitem><para> Internet Message Access Protocol (IMAP, IETF RFC 1730), IMAP 
+<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 
+over
 
 SSL/TLS (IETF RFC 2595) </para></listitem>
-<listitem><para> Hyper Text Transfer Protocol (HTTP, IETF RFC 2616), HTTP over 
+<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 
+criteria
 
 but
 seems to be widely accepted and free implementations exist) </para></listitem>
@@ -43,25 +42,25 @@
 
 <sect1><title> Used File Standards </title>
 <itemizedlist>
-<listitem><para> multi-part MIME email as standardized by the IETF 
+<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 
+Consortium
 (http://www.imc.org) </para></listitem>
 </itemizedlist>
 </sect1>
 
 <sect1><title> Sending Email </title>
-<para>The Kolab server runs the Postfix Mail Transfer Agent (MTA) and acts as 
+<para>The Kolab server runs the Postfix Mail Transfer Agent (MTA) and acts as
 SMTP relay for all users.
-It is however possible to decouple this functionality from the mailboxes and 
+It is however possible to decouple this functionality from the mailboxes and
 establish it on another server,
 for load-sharing and high availability purposes.
 Security is provided using two methods:</para>
 <orderedlist>
-<listitem><para> on application level: Email can be encrypted using PGP/GPG 
+<listitem><para> on application level: Email can be encrypted using PGP/GPG
 </para></listitem>
-<listitem><para> on the transport level: the SMTP relay accepts SMTP over TLS 
+<listitem><para> on the transport level: the SMTP relay accepts SMTP over TLS
 connections </para></listitem>
 </orderedlist>
 <para>For compatibility reasons, plain SMTP is also supported.</para>
@@ -70,9 +69,9 @@
 <sect1><title> Receiving Email </title>
 <para>Users read their email via IMAP over TLS on the Kolab server. New user
 accounts are created on the
-Kolab server only within IMAP (not as regular GNU/Linux accounts), using the 
+Kolab server only within IMAP (not as regular GNU/Linux accounts), using the
 mailbox name
-<filename>user.<username></filename>. The latter is a requirement 
+<filename>user.<username></filename>. The latter is a requirement
 resulting from the Cyrus IMAP daemon.</para>
 <para> The Postfix MTA on the groupware server delivers email for local
 users to the Cyrus IMAP Daemon via the Local Mail Tranport Protocol (LMTP)
@@ -88,7 +87,7 @@
 The email messages are transferred via IMAP synchronization to the client
 application. This synchronization
 functionality also provides the required offline functionality.</para>
- 
+
 <para> The messages are identified via a unique id.
 Optionally, users can physically receive their email messages via POP3 over SSL
 from the groupware server
@@ -104,7 +103,7 @@
 </sect1>
 
 <sect1><title> Vacation Functionality </title>
-<para>The vacation functionality is configured by the user via a simple 
+<para>The vacation functionality is configured by the user via a simple
 webinterface available via HTTPS provided by the Kolab server. The actual
 vacation
 functionality is implemented on the server
@@ -125,7 +124,7 @@
 <sect1><title> Contacts </title>
 <para>The client application stores contacts in the IMAP subfolder named
 "Contacts"
-(German: "Kontakte") on the Kolab server. The actual entries are represented as 
+(German: "Kontakte") on the Kolab server. The actual entries are represented as
 multi-part
 MIME emails with included vCard address data as MIME parts.
 See the appendix for the exact file format.</para>
@@ -135,14 +134,16 @@
 <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 
+access
 
 it by using
-the LDAP v3 protocol. The GUI on the client provides read only access to all 
+the LDAP v3 protocol. The GUI on the client provides read only access to all
 address data stored
 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
 therefor a plain web interface is sufficient. A user can modify his own LDAP
@@ -151,98 +152,188 @@
 </sect1>
 
 <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.
-See the appendix for the exact file format and examples.</para>
-
-<para>Group calendar entries are stored just like personal events in the same 
-IMAP sub folder on the Kolab
-server. The difference between private and group calendar events is simply a 
-matter of the iCalendar
-information being part of several users calendars. They are shared via 
-exchanging multi-part MIME
-emails and have to be accepted and therewith put into their
-respective calendar folders by the attendees.
+<para>Calendar entries are stored in the users IMAP store. Like all
+normal folders the Calendar folder is a subfolder of the users INBOX.
+For every account including normal users account, resource accounts and group
+accounts one of the potentially many calendar folders is marked as the default
+calenendar using the IMAP annotation extension.
+</para>
+<para>
+Calendar entries are represented as multi-part MIME messages with
+the information stored in the Kolab XML format. In addition to the XML part a
+client may choose to store data in an additional MIME part. E.g. both the
+Toltec Connector and the Konsec Outlook Connector chose to use an additional
+TNEF MIME part.
+</para>
+<para>
+The Kolab clients must preserve any unknown MIME part and any unknown XML tag.
+</para>
+<para>
+The iCalendar format encapsulated in a MIME part used by the Kolab 1 KDE client
+is still available as an option for those not requiring full interoperability
+with MS Outlook clients.
+</para>
+<para>
+Please see the appendix for the exact file formats and examples.
+</para>
+<para>
+Kolab 2 allows a more sophisticated concept for modelling group calendaring.
+While Kolab 1 basically build upon the abilities to upload and retrieve
+freebusy information and invitations via SMTP emails Kolab 2 allows the
+simultaneous sharing of group accounts across client platforms.
+</para>
+<para>
+In order to be able to share the same account across users and platforms the
+cross platform Kolab XML format was developed. In addition the sharing is more
+sophisticated now with the ability to manage access with ACLs. ACLs are much
+superiour to sharing passwords with regards to flexibility and security).
+</para>
+<para>
+The concept of plain freebusy lists (fb) is enhanced with the possibilty of
+extended freebusy lists (xfb). Extended free busy lists are not intended for
+the simple gantt diagrams in the Kolab clients but for extended reporting
+features using the Kolab webinterface.
+</para>
+<para>
+The ability of storing group events just like personal events in
+the same IMAP sub folder on the Kolab server remains in case the group event is
+created by traditional invitations.  These group events are shared via
+exchanging multi-part MIME emails using iCalendar format and have to be accepted
+and therewith put into their respective calendar folders by the attendees. The
+handling of acceptance status is a unique featue of the traditional group
+scheduling.
+</para>
+<para>
 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.
+data covering a user definable time range into the future. This time range is a
+user specific setting in the LDAP directory.
+</para>
+<para>
+Free-busy lists are published on the Kolab server and are available via https.
 The free-busy lists are referenced via URLs and are retrievable by all
 registered clients from the Kolab server. The free-busy lists are
-named after the rule <filename><username>.vfb</filename> and
-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>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.
+named after the rule <filename><username>.ifb</filename> and
+follow the iCalendar file format.
 </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.
+Kolab 2 is able to create the free-busy lists on the server so that the clients
+currently don't need to publish free-busy lists anymore.
 </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 
+In the future clients may upload free-busy lists to the Kolab server using
+secure WebDAV. This will be useful for calendars not being stored on the Kolab
+server but which still relevant for the free-busy status of a user. Such a usage
+model might for example be motivated by privacy concerns.
+</para>
+<para>
+The free-busy list of a user is the consolidated superset of all free-busy
+relevant calendars.
+</para>
+<para>
+The relevance of a calendar folder is controlled by the presence of a free-busy
+annotation flag.  The availability of such a flag means that this folder shall
+be taken into account for the generation of the free-busy list.
+</para>
+<para>
+This allows a Kolab user to organize her calendaring by having many
+calendars folders in one account.
+ </para>
+<para>
+Group calendars with the free-busy annotation set are taking into account for
+the free-busy lists for all Kolab users having read permissions on this calendar
+folder.
+</para>
+<para>
+Conceptually this means that the administrators of the group account push the
+free-busy relevants on the Kolab users by means of granting them read access.
+</para>
+
+<para>Support for insecure FTP and HTTP protocols to upload and download
+free-busy lists is removed from Kolab 2.
+</para>
+<para>
+For the future upload capability of private local free-busy information to the
+Kolab server Windows XP systems can use secure WEBDAV to upload freebusy
+lists like KDE clients are able to do since Kolab 1. The WEBDAV
+functionality can obtained for legacy Windows 2000 clients using the Novell
+Webdrive or other 3rd party software which allows to map a WEBDAV resource to a
+drive letter.
+</para>
+<para>
+The Kolab 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. 
+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 
+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 
+applications. The server mainly acts as a network storage in this
 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 
+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
+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 foure 
-cases for any automatic account. This behaviour is configurable in the LDAP directory.
+For resource and group accounts it is possble to configure the behaviour in case
+of a conflict. We only implement the following foure
+cases for any automatic account. This behaviour is configurable in the LDAP
+directory.
 
 <itemizedlist mark='bullet'>
 <listitem>
 <para>
-ignore conflicts, accept if sender is in allow list, queue if sender is not in allow list
+ignore conflicts, accept if sender is in allow list, queue if sender is not in
+allow list
 </para>
 </listitem>
 <listitem>
 <para>
-ignore conflicts, accept if sender is in allow list, reject if sender is not in allow list
+ignore conflicts, accept if sender is in allow list, reject if sender is not in
+allow list
 </para>
 </listitem>
 <listitem>
@@ -256,52 +347,70 @@
 </itemizedlist>
 </para>
 <para>
-The sender is always informed via traditional accept and reject invitation messages equivalent to normal non automatic invitations.
+The sender is always informed via traditional accept and reject invitation
+messages equivalent to normal non automatic invitations.
 </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.
+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.
+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. <email>Audi.A4 at kolab.erfrakon.de</email> or <email>marketing at kolab.erfrakon.de</email>.
+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.
+<email>Audi.A4 at kolab.erfrakon.de</email> or
+<email>marketing at kolab.erfrakon.de</email>.
 </para>
 </sect1>
 
 <sect1><title>Extended Freebusy lists</title>
-<para>A server process based on the webclient 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>A server process based on the webclient 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.
 The webclient talks to the Cyrus IMAP server with the credentials of the user.
 </para>
 <para>
-The individual account must allow the extended freebusy list user access to its calendar folder otherwise the calendar folder of this user is simply skipped.
+The individual account must allow the extended freebusy list user access to its
+calendar folder otherwise the calendar folder of this user is simply skipped.
 </para>
 <para>
-The server process generates a html gantt chart with a row for each individual user and an aggregated row with the summed up freebusy times.
+The server process generates a html gantt chart with a row for each individual
+user and an aggregated row with the summed up freebusy times.
 We reuse the gantt code from the Taskjuggler project.
 </para>
 </sect1>
 
 
 <sect1><title> Notes </title>
-<para>Notes are stored on the Kolab server inside the users IMAP sub folder 
+<para>Notes are stored on the Kolab server inside the users IMAP sub folder
 "Notes" (German: "Notizen").
-Physically, they are represented as multi-part MIME emails with the actual note 
+Physically, they are represented as multi-part MIME emails with the actual note
 being a MIME part.
 See the appendix for the exact file format.</para>
 </sect1>
 
 <sect1><title> Task Lists </title>
 <para>Task lists are stored on the Kolab server inside the users IMAP sub
-folder 
+folder
 
 "Tasks" (German: "Aufgaben").
 Physically, they are multi-part MIME emails with the actual task list data
-being 
+being
 
 a MIME part and
 following the iCalendar standard (vToDo, IETF RFC 2446).
@@ -310,25 +419,26 @@
 
 <sect1><title> Management of Shared Resources </title>
 
-<para>The Kolab server assigns a dedicated IMAP identity to every shared 
+<para>The Kolab server assigns a dedicated IMAP identity to every shared
 resource. These identities do not
-differ technically from real users. Reserving a car or a room for example is 
+differ technically from real users. Reserving a car or a room for example is
 just arranging a meeting with the shared resource's assigned IMAP user.
 Two modes of operation are supported:
 </para>
 
 <orderedlist>
 <listitem>
-<para> 
+<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.
+in addition to his own mailbox and accepts or declines events on behalf of the
+shared resource.
 </para>
 </listitem>
-<listitem><para> automatic mode: via Sieve scripting the resource mailbox is 
+<listitem><para> automatic mode: via Sieve scripting the resource mailbox is
 monitored;
-the scripting takes care of automatically publishing it's free-busy list and 
+the scripting takes care of automatically publishing it's free-busy list and
 accepts or declines
-events on the basis of availability of the resource 
+events on the basis of availability of the resource
 </para></listitem>
 </orderedlist>
 
@@ -336,12 +446,13 @@
 
 <sect1><title>Access Control and Multiple Identities</title>
 <para>
-Every user has its own personal account with full administrative priviledges. 
+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.
+ 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>
@@ -349,9 +460,11 @@
 <varlistentry><term><filename>Personal distribution list</filename></term>
 <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
+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>
@@ -387,92 +500,121 @@
 </para>
 
 <para>
-The KDE Kolab client gets central distribution list from LDAP and is able to create a local 
+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 
+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
+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 <emphasis>not</emphasis> 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.
+When accessing folders of other users the identitiy of the user does
+<emphasis>not</emphasis> 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>
 
 <para>
 <orderedlist>
 <listitem>
 <para>
-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.
+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.
 </para>
 </listitem>
 <listitem>
 <para>
-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.
+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.
 </para>
 </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. 
+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 
+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 
+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. 
+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
+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.
+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.
+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 
+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 
+ 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 
+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 
+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>





More information about the commits mailing list