martin: doc/architecture client_client.sgml, 1.6, 1.7 client_server.sgml, 1.21, 1.22 concept.sgml, 1.16, 1.17 kde.sgml, 1.7, 1.8 overview.sgml, 1.8, 1.9 server.sgml, 1.28, 1.29 windows.sgml, 1.9, 1.10
cvs at intevation.de
cvs at intevation.de
Wed Nov 3 07:27:58 CET 2004
Author: martin
Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv20858
Modified Files:
client_client.sgml client_server.sgml concept.sgml kde.sgml
overview.sgml server.sgml windows.sgml
Log Message:
Martin K.: Fixed spelling by native speaker
Index: client_client.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_client.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- client_client.sgml 3 Oct 2004 18:56:28 -0000 1.6
+++ client_client.sgml 3 Nov 2004 06:27:56 -0000 1.7
@@ -23,7 +23,7 @@
<sect1><title> Group Event Notifications </title>
<para>Invitations to a group event are sent via a multi-part MIME email with
iCalendar information
-included as a MIME part. The user can decide to either accept the event (and
+included as a MIME part. The user can decide either to accept the event (and
thereby
import it into his own calendar) or decline it. When an event is declined, an
according email
Index: client_server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_server.sgml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -d -r1.21 -r1.22
--- client_server.sgml 27 Oct 2004 22:32:43 -0000 1.21
+++ client_server.sgml 3 Nov 2004 06:27:56 -0000 1.22
@@ -16,7 +16,7 @@
<para>In general simplicity is preferred over complexity. The
limitation to a small set of well-established and widely used protocols is a
major design goal.</para>
-<para>This leads to the following protocols being used in the
+<para>This leads to the following protocols used in the
project:</para>
<itemizedlist>
<listitem><para> Lightweight Directory Access Protocol Version 3 (LDAP, IETF RFC
@@ -33,7 +33,7 @@
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
+<listitem><para> HotSync Protocol (this does not gather some of the above
criteria
but
@@ -57,7 +57,7 @@
<sect1><title> Sending Email </title>
<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
+However it is 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>
@@ -67,7 +67,7 @@
<listitem><para> on the transport level: the SMTP relay accepts SMTP over TLS
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.
+<listitem><para> on the transport level: for Kolab users we use sender authentification so that recipients can trust in the from-address of Kolab messages.
</para></listitem>
</orderedlist>
</sect1>
@@ -77,7 +77,7 @@
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)
+users to the Cyrus IMAP Daemon via the Local Mail Transport Protocol (LMTP)
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>
@@ -94,16 +94,16 @@
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>POP3 capabilities are a mandatory requirement for proper functioning of 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
+access a Kolab server's mailboxes and distribute email messages via the Kolab server, provided that 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 or builtin SIEVE capabilities
+webinterface available via HTTPS provided by the Kolab server or built-in 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
@@ -112,8 +112,8 @@
Note that Sieve's capabilities reach far beyond a simple vacation functionality.
Therefore we
gain great flexibility for future extensions. The server side scripting is a
-sensitive area though,
-as such activities run contrary to server scalability and performance and
+sensitive area
+e.g. activities run contrary to server scalability and performance and
therefore must be used
with caution if we intend scalability to many thousands of users on commodity
hardware.</para>
@@ -181,7 +181,7 @@
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).
+superior in sharing passwords with regards to flexibility and security.
</para>
<para>
The concept of plain freebusy lists (fb) is enhanced with the possibilty of
@@ -217,7 +217,7 @@
<para>
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
+server but which are still relevant for the free-busy status of a user. Such a usage
model might for example be motivated by privacy concerns.
</para>
<para>
@@ -250,11 +250,11 @@
</para>
<para>
-The incidences-for annotation is used for calendars and tasks.
+The incidencesfor annotation are used for calendars and tasks.
</para>
<para>
-This allows a Kolab user to organize her calendaring by having many
+This allows a Kolab user to organize the calendaring by having many
calendars folders in one account.
</para>
<para>
@@ -273,7 +273,7 @@
<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
+lists like KDE clients are able to do this 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.
@@ -285,11 +285,11 @@
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
+personal or central distribution lists. For 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.
+for all members, some members or busy for everyone.
</para>
<para>
An analogous gantt chart interface is also implemented on the Kolab server using
@@ -318,7 +318,7 @@
<sect1><title>Automatic rules based handling of invitations</title>
<para>
The Kolab server implements a server side mechanism for handling of invitations.
-Typically this feature is used to handle bookings of resources (e.g. a room,
+This feature is typically used to handle bookings of resources (e.g. a room,
car, lcd projector etc.).
</para>
<para>
@@ -371,7 +371,7 @@
</para>
<para>
The invitation is accepted in case there is no conflict with other
-appointments and immediately rejected otherwiese. The check happens by refering
+appointments and immediately rejected otherwise. The check happens by refering
to the uptodate free-busy list.
</para>
</listitem>
@@ -381,7 +381,7 @@
</para>
<para>
The invitation is accepted in case there is no conflict with other
-appointments. In case a conflixt is detected the invitation is queued in the
+appointments. In case a conflict is detected the invitation is queued in the
INBOX. It is expected that a user is manually maintaining the INBOX regularily.
</para>
</listitem>
@@ -390,7 +390,7 @@
ACT_MANUAL
</para>
<para>This is the default case for every account. Invitations are just queued in
-the INBOX of the recipient. The recipient then decides upon the request manually
+the INBOX of the recipient. The recipient then decides upon the request manually.
</para>
</listitem>
</itemizedlist>
@@ -476,7 +476,7 @@
<orderedlist>
<listitem>
<para>
-manual mode: a real user monitors a shared resources mailbox
+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.
</para>
@@ -485,7 +485,7 @@
monitored;
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>
@@ -493,9 +493,9 @@
<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
+Every user has its own personal account with full administrative privileges.
+This means that every user is allowed to manage the access permission of all
+folders belonging to him. The user may use these privileges 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
@@ -577,7 +577,7 @@
<orderedlist>
<listitem>
<para>
-Folders of other users with explicit access priviledges granted either to the
+Folders of other users with explicit access privileges 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.
@@ -605,7 +605,7 @@
<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.
+for all other activities like invitations, accepting meetings, tasks etc.
</para>
<para>
For groupware folders (calendars, contacts, tasks and notes) this has to be
@@ -631,7 +631,7 @@
<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
+so that the subfolder is indeed accessable to the other users of the group. This is
analogous to traditional unix filesystem permissions.
</para>
<para>
@@ -643,7 +643,7 @@
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
+The Outlook Plugin could be extended to provide a better user interface for this
szenario.
In Kontact this functionality is provided analogous to choosing the sender
identity
@@ -660,8 +660,8 @@
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
+default address. This address is afterwards like all sender addresses
+subject to LDAP based canonification
(e.g. konold at erfrakon.de is rewritten to martin.konold at erfrakon.de).
</para>
<para>
@@ -675,7 +675,7 @@
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
-client installation and as such are not related to the client server
+client installation and is as such not related to the client server
communication.
</para>
</sect1>
Index: concept.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/concept.sgml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- concept.sgml 18 Oct 2004 05:56:38 -0000 1.16
+++ concept.sgml 3 Nov 2004 06:27:56 -0000 1.17
@@ -46,11 +46,11 @@
</para>
<para>
All other herein mentioned trademarks belong
-to their respective owners. Use of a term in this book should not be regarded as
+to their respective owners. The use of a term in this book should not be regarded as
affecting the validity of any trademark or service mark.
</para>
<para>
-Finally, the authors of this book are not liable for any errors found as well as anything that may cause a fault. However, if that does occur, please notify the authots so corrections can be made. Furthermore, the reader must also agree to use the information in this book at his/her own risk and relinquish the authors, from any mistakes due to this book. If not, please stop reading now.
+Finally, the authors of this book are not liable for any errors found as well as anything that may cause a fault. However, if that does occur, please notify the authors that corrections can be made. Furthermore, the reader must also agree to use the information in this book at his/her own risk and relinquish the authors, from any mistakes due to this book. If not, please stop reading now.
</para>
<para>
BECAUSE THE CONTENT IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE CONTENT, TO THE EXTENT PERMITTED BY APPLICABLE LAW. THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE CONTENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK OF USE OF THE CONTENT IS WITH YOU. SHOULD THE CONTENT PROVE FAULTY, INACCURATE, OR OTHERWISE UNACCEPTABLE YOU ASSUME THE COST OF ALL NECESSARY REPAIR OR CORRECTION.
Index: kde.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/kde.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- kde.sgml 20 Oct 2004 05:38:51 -0000 1.7
+++ kde.sgml 3 Nov 2004 06:27:56 -0000 1.8
@@ -1,6 +1,6 @@
<chapter><title> The KDE Client </title>
<para>The KDE client is implemented using these existing Free Software KDE
-projects and their technologies. This development development effort is directly
+projects and their technologies. This development effort is directly
conducted in the KDE CVS repository and shall be integrated in future releases
of the existing Free Software projects:</para>
<itemizedlist>
@@ -14,8 +14,8 @@
<itemizedlist>
<listitem><para> Integrate the components with the graphical Kontact shell. Kontact acts as a
kparts container and runs all the KDE componentes for the PIM solution as embedded kparts. </para></listitem>
-<listitem><para> Add proper offline support to the IMAP kioslave called disconnected IMAP (dIMAP)</para></listitem>
-<listitem><para> Extend the GUI to support further functionality </para></listitem>
+<listitem><para> Add proper offline support to the IMAP kioslave called disconnected IMAP (dIMAP).</para></listitem>
+<listitem><para> Extend the GUI to support further functionality. </para></listitem>
<listitem><para> implement the new Kolab XML storage format in addition to the existing iCalendar format
in order to become fully interoperable with clients that are not based on KOrganizer (e.g. Outlook based clients).
</para></listitem>
@@ -39,7 +39,7 @@
IMAP annotation allows us to add small annotations to an IMAP folder describing
its use. Currently annotations are used to define calendar, task and contact folders.
One of each categorie of groupware folders is defined as the default folder for its type.
-E.g. there is always a default calendar which is used for mergeing incoming event requests
+E.g. there is always a default calendar which is used for merging incoming event requests
etc. In addition IMAP folder annotations are used for marking calendars as relevant for the creation of freebuys
information.
Basically this means that the Kolab 2 clients will be interoperable with each
Index: overview.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/overview.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- overview.sgml 18 Oct 2004 05:56:38 -0000 1.8
+++ overview.sgml 3 Nov 2004 06:27:56 -0000 1.9
@@ -7,18 +7,18 @@
testing was done on Debian and SUSE.
</para>
<para>
-We minimized the usage of Linux distribution dependencies in order to gain maximal portability. In order to be
+We minimized the usage of Linux distribution dependencies in order to gain maximum 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
+these vendors can be installed without affecting the Kolab server´s
functionality.</para>
<para>
The Kolab server is distributed as OpenPKG packages which allows for a single
source for our many target platforms.
</para>
<para>
-It is not the scope of this architecuture to integrate with the underlaying
+It is not the scope of this architecture to integrate with the underlaying
operating system in such a way that the administration of the operating system
is accomplished with it.
</para>
@@ -26,7 +26,7 @@
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
+the complete free software groupware solution, seen from the users point of view,
follows. The list was created with existing proprietary groupware products in
mind, namely Microsoft Exchange Server with Outlook 2002 clients on Windows NT.</para>
@@ -37,7 +37,7 @@
<listitem><para> sending
email via SMTP over TLS and receive it via IMAP over TLS (preferably) or plain
SMTP and IMAP (alternatively for backward compatibility 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> support for strong cryptography for email bodies and attachments in addition to the security features provided by the transmission protocol (which 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</para>
@@ -54,8 +54,7 @@
private address book is stored on the Kolab server in IMAP folders. A bidirectional vCard
interface is provided. In consequence, vCards received as email attachments can
be easily added to a users contacts.</para>
-<para>In Kolab 2 the newly introduced cross-platform XML-storage format is
-introduced which allows for a server side personal addressbook which is
+<para>In Kolab 2 the newly introduced cross-platform XML-storage format allows a server side personal addressbook.This is
interchangeable between Kolab clients including Microsoft Outlook with the
Toltec Connector.
<para>In Kolab 2 a user may have multiple contact folders. One is marked as
@@ -77,7 +76,7 @@
for other users using published free-busy lists ,the exact event information is hidden from them. They only see
that a given private event of another user exists.
Private events are saved on the Kolab server in an IMAP folder. Users can schedule group events and invite other users. An
-existing group event can be modifiedby the user who originally created it.
+existing group event can be modified by the user who originally created it.
Examples for group events are:<itemizedlist>
<listitem><para>Group meetings</para></listitem>
<listitem><para>Conferences</para></listitem>
@@ -95,14 +94,14 @@
<sect1><title> Notes </title>
<para> A user may take private notes which are then stored on the Kolab server.
-Notes can easily be mailed to other users and there with shared with them, as
+Notes can easily be mailed to other users and shared with them, as
copies in addition to sharing them via IMAP.</para></sect1>
<sect1><title> Task Lists </title>
-<para>Users can maintain task lists with priorities. Task lists are saved on the
-Kolab server. Items on the task list can be assigned to different users and are
+<para>Users can maintain task lists with priorities. These are saved on the
+Kolab server. Items on the task list can be assigned to different users and
added to their task lists as well, as they receive and accept them. Task lists
-are private if no items are assigned to other users.</para>
+are private if no items are meant for other users.</para>
<para>Task list may be shared using IMAP folders</para>
</sect1>
Index: server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/server.sgml,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- server.sgml 29 Oct 2004 04:41:26 -0000 1.28
+++ server.sgml 3 Nov 2004 06:27:56 -0000 1.29
@@ -47,7 +47,7 @@
</para>
<para>
A directory service is optimized for speed with regards to read operations. A typical Kolab LDAP directory
-server fits even for very large installation in the main memory of the machine running the servies. In order to
+server fits even for very large installation in the main memory of the machine running the services. In order to
further speed up common search operations we use indices.
</para>
<para>
@@ -1278,7 +1278,7 @@
<sect1><title>Antivirus and Antispam Daemon</title>
<sect2><title>Antivirus - Amavis Daemon</title>
-<para>amavisd is a high-performance interface between mailer (Postfix) and content checkers: virus scanners (ClamAV) and
+<para>Amavisd is a high-performance interface between mailer (Postfix) and content checkers: virus scanners (ClamAV) and
antispam scanners (SpamAssassin). It is written in Perl for maintainability, without paying a significant price for speed.
It talks to Postfix via ESMTP.
</para>
@@ -1287,7 +1287,7 @@
OpenPKG package.
</para>
<para>
-Amavis uses directories for unpacking, quarantining
+Amavisd uses directories for unpacking, quarantining
infected messages, and quarantining messages that it could not process
correctly. These directories must exist and be writable by
amavis when it starts.
@@ -1391,7 +1391,7 @@
<sect2><title>Free Software Antivirus Scan Engine ClamAV</title>
<para>The costs of scanning for viruses and other malware skyrocks while the quality of many proprietary
virus scanner option declines. A special problem is here the need for the supplier of proprietary software for
-diversivication. This leads to technically suboptimal solutions like large and unreliable
+diversivication. This leads to technical suboptimal solutions like large and unreliable
software for the plain download of pattern files. We therefore experience for example ever changing download URLS for
new patterns and the need to update many components of the solution regularily.
</para>
@@ -1902,20 +1902,20 @@
Normally, in order for a message to be inserted into a mailbox, the quota root for the mailbox must have enough unused storage so that inserting the message will not cause the block quota to go over the limit.
</para>
<para>
-Mail delivery is a special case. In order for a message to be delivered to a mailbox, the quota root for the mailbox must not have usage that is over the limit. If the usage is not over the limit, then one message may be delivered regardless of its size. This puts the mailbox's usage over the quota, causing a user to be informed of the problem and permitting them to correct it. If delivery were not permitted in this case, the user would have no practical way of knowing that there was mail that could not be delivered.
+Mail delivery is a special case. In order for a message to be delivered to a mailbox, the quota root for the mailbox must not have usage that is over the limit. If the usage is not over the limit, then one message may be delivered regardless of its size. This puts the mailbox's usage over the quota, causing a user to be informed of the problem and permitting them to correct it. If delivery were not permitted in this case, the user would have no practical way of knowing that there was a mail that could not be delivered.
</para>
<para>
If the usage is over the limit, then the mail delivery will fail with a temporary error. This will cause the delivery system to re-attempt delivery for a couple of days (permitting the user time to notice and correct the problem) and then return the mail to the sender.
</para>
<para>
-The Kolab clients must bea able to handle the hard quota limit and provide a localized and meaningful error message.
+The Kolab clients must be able to handle the hard quota limit and provide a localized and meaningful error message.
The message which could not get synchronized must remain in the folder. User is ask to manually solve the problem e.g.
deletion of messages.
</para>
<para>
Each maintainer of a domain gets a daily quota report via email. This report has different sections for hard quota, soft quota and filesystem usage for everyone else. The frequency or disabling of this feature is
-configurable by an administrator. (No GUI currently)
+configurable by an administrator (No GUI currently).
</para>
<para>In order to be able to deal with quotas correctly the KDE client must first delete messages before trying to send new messages.
@@ -2004,7 +2004,7 @@
</para>
<para>
The basic idea is that all Kolab server see the very same directory and learn from the homeServer LDAP attribute which are their users. Every Kolab server knows about <emphasis>all</emphasis> Kolab users and therefore is able to grant access to folders to
- users belonging to different Kolab home servers. In addition this makes moving users from one location to the other very easy.
+ users belonging to different Kolab home servers.
</para>
<para>
In addition this makes moving users from one location to the other very easy as the required account is already known to the target
Index: windows.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/windows.sgml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- windows.sgml 11 Oct 2004 15:44:53 -0000 1.9
+++ windows.sgml 3 Nov 2004 06:27:56 -0000 1.10
@@ -26,7 +26,7 @@
</para>
<para> For http access of the freebusy information on the Kolab server a valid username and password has to be given. The credentials
-will be verified via SASL authenticaton on the LDAP directory of the server.
+will be verified via SASL authentication on the LDAP directory of the server.
The procedure of setting the required options within Outlook follows (german version).
One can also refer to the excellent Toltec Connector documentation <filename>http://www.toltec.co.za/downloads/tokhowto-1.0.pdf</filename> for doing this.
</para>
More information about the commits
mailing list