martin: doc/architecture client_server.sgml,1.13,1.14
cvs at intevation.de
cvs at intevation.de
Tue Oct 19 08:21:36 CEST 2004
Author: martin
Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv14931
Modified Files:
client_server.sgml
Log Message:
Martin K.: Update of contacts, address book and calendar
Index: client_server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_server.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- client_server.sgml 3 Oct 2004 18:56:28 -0000 1.13
+++ client_server.sgml 19 Oct 2004 06:21:34 -0000 1.14
@@ -41,13 +41,16 @@
</itemizedlist>
</sect1>
-<sect1><title> Used File Standards </title>
+<sect1><title> Used File Format Standards </title>
<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
(http://www.imc.org) </para></listitem>
+<listitem><para> XML Kolab format as standardized by the Kolab community (http://www.kolab.org/)
+</para></listitem>
+
</itemizedlist>
</sect1>
@@ -59,55 +62,49 @@
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 the application level: Email can be encrypted using OpenPGP/GPG
</para></listitem>
<listitem><para> on the transport level: the SMTP relay accepts SMTP over TLS
-connections </para></listitem>
+connections </para><para>For compatibility reasons, plain SMTP is also supported.</para>
+</listitem>
+<listitem><para> on the transport level: for Kolab users we do sender authentification so that recipients can trust in the from-address of Kolab messages.
+</para></listitem>
</orderedlist>
-<para>For compatibility reasons, plain SMTP is also supported.</para>
</sect1>
<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
-mailbox name
-<filename>user.<username></filename>. The latter is a requirement
-resulting from the Cyrus IMAP daemon.</para>
+<para>Users read their email via TLS secured IMAP from the Kolab server. New user
+accounts are created on the Kolab server as LDAP based Kolab accounts (not as regular GNU/Linux accounts), using the mailbox name <filename>user.<username></filename> below the <filename>domain</filename> hierarchie. The latter is a requirement
+resulting from the Cyrus IMAP daemon and prepares for future multi-domain capabilities.</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)
-to their respective IMAP mailboxes, which are implemented in the
-maildir format
-(not traditional mbox style, every email is a regular GNU/Linux text
+to their respective IMAP mailboxes, which are implemented in a format similar to the
+maildir format (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
-mailbox <filename>user.<username></filename> to a configurable directory
+ <para> The emails are then further processed by the users client desktop application. Note that Cyrus maps
+the above mentioned mailbox <filename>user.<username></filename> to a configurable directory
tree within the Kolab servers filesystem.
The email messages are transferred via IMAP synchronization to the client
-application. This synchronization
+application using the disconnected IMAP capabilites of the client. This synchronization
functionality also provides the required offline functionality.</para>
-<para> The messages are identified via a unique id.
+<para> The messages are identified via a unique IMAP id.
Optionally, users can physically receive their email messages via POP3 over SSL
from the groupware server
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>POP3 capabilities are a mandatory requirement for proper functioning of the the Toltec Connector
+</para>
<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
-and the corresponding password. </para>
+access a Kolab server's mailboxes and distribute email messages via the Kolab server, provided the server IP
+address, the username and the corresponding password are correct. </para>
</sect1>
<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
-functionality is implemented on the server
+webinterface available via HTTPS provided by the Kolab server or builtin SIEVE capabilities
+in the client. The actual vacation functionality is implemented on the server
using Sieve (IETF RFC 3028).
A Free Software implementation of this scripting language
for the Cyrus IMAP daemon is available.</para>
@@ -123,41 +120,39 @@
</sect1>
<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
-multi-part
-MIME emails with included vCard address data as MIME parts.
+<para>The client application stores contacts in IMAP subfolders marked using
+IMAP annotations as contact folders on the Kolab server. The actual entries are represented as
+multi-part MIME emails with included Kolab XML format address data as MIME parts. A single contact folder is marked as the default contact folder.
+</para>
+<para>
See the appendix for the exact file format.</para>
</sect1>
<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
-
-it by using
-the LDAP v3 protocol. The GUI on the client provides read only access to all
-address data stored
-inside the directory.</para>
+Kolab server 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
+address data stored inside the directory.</para>
+<para>
+The global address book is maintained via the Kolab web administration GUI or any other readily available
+LDAP tool.
+</para>
<para> The LDAP scheme is designed in order to allow easy
-bidirectional conversion to vCard.</para>
+bidirectional conversion to vCard and the Kolab XML format.</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
+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>
</sect1>
<sect1><title> Groupware Calendar </title>
<para>Calendar entries are stored in the users IMAP store. Like all
-normal folders the Calendar folder is a subfolder of the users INBOX.
+normal folders the Calendar folders are subfolders 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.
+calendar using the IMAP annotation extension.
</para>
<para>
Calendar entries are represented as multi-part MIME messages with
@@ -166,12 +161,12 @@
Toltec Connector chooses to use an additional TNEF MIME part.
</para>
<para>
-The Kolab clients must preserve any unknown MIME part and any unknown XML tag.
+The Kolab clients must preserve any unknown MIME part and any unknown XML tags.
</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.
+with MS Outlook / Toltec clients.
</para>
<para>
Please see the appendix for the exact file formats and examples.
@@ -249,7 +244,7 @@
</para>
<para>Support for insecure FTP and HTTP protocols to upload and download
-free-busy lists is removed from Kolab 2.
+free-busy lists is discouraged for Kolab 2.
</para>
<para>
For the future upload capability of private local free-busy information to the
@@ -282,15 +277,12 @@
</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
+by the client 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.
+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
More information about the commits
mailing list