martin: doc/architecture Makefile, 1.8, 1.9 client_server.sgml, 1.11, 1.12

cvs at intevation.de cvs at intevation.de
Sun Oct 3 06:34:19 CEST 2004


Author: martin

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

Modified Files:
	Makefile client_server.sgml 
Log Message:
Martin K.: Added Kolab Invitation policies


Index: Makefile
===================================================================
RCS file: /kolabrepository/doc/architecture/Makefile,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- Makefile	29 Apr 2004 18:10:25 -0000	1.8
+++ Makefile	3 Oct 2004 04:34:17 -0000	1.9
@@ -37,7 +37,7 @@
 concept/index.html: $(SGML_SRC) $(INCLUDED_SRCS)
 	$(HTML_CMD) $(SGML_SRC)
 	cp erfrakon.png $(HTML_DEST_DIR)/
-	mv $(HTML_DEST_DIR)/index.html $(HTML_DEST_DIR)/index.html.tmp
+	cp $(HTML_DEST_DIR)/index.html $(HTML_DEST_DIR)/index.html.tmp
 	cat $(HTML_DEST_DIR)/index.html.tmp | sed -e 's/SRC=\"erfrakon\"/SRC=\"erfrakon\.png\"/g' > $(HTML_DEST_DIR)/index.html
 	rm $(HTML_DEST_DIR)/index.html.tmp
 

Index: client_server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_server.sgml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- client_server.sgml	3 Oct 2004 03:34:45 -0000	1.11
+++ client_server.sgml	3 Oct 2004 04:34:17 -0000	1.12
@@ -299,77 +299,108 @@
 </para>
 </sect1>
 
-<sect1><title>Automatic rules based accepting of invitations</title>
+<sect1><title>Automatic rules based handling 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.
+The Kolab server implements a mechanism for handling of invitations.
+Typically this feature is used to handle bookings of resources (e.g. a room,
+car, lcd projector etc.).
 </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 the automatic handling of invitations access control lists are used which
+define the action to be taken depending on the senders address.
+</para>
+<para>
+These ACLs are maintained in the LDAP directory. In case no ACL does match the
+request is queued in the INBOX of the recipient and the sender is informed about
+the fact that his request is pending.
+</para>
+<para>
+There are five different kind of Kolab invitation policy ACLs. Typically these
+values are prefixed with the primary email address of a sender to whom they
+shall apply. An omitted prefix represents an anonymous policy and means "apply
+to everyone".
+</para>
+<para>
+The sender is always informed via traditional accept and reject invitation
+messages using iCalendar format.
+</para>
 
 <itemizedlist mark='bullet'>
 <listitem>
 <para>
-ignore conflicts, accept if sender is in allow list, queue if sender is not in
-allow list
+ACT_ALWAYS_ACCEPT
+</para>
+<para>
+In this case no conflict detection is taking place. If the organizer (sender of
+the invitation) changes the appointment this information is also 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.
 </para>
 </listitem>
 <listitem>
 <para>
-ignore conflicts, accept if sender is in allow list, reject if sender is not in
-allow list
+ACT_ALWAYS_REJECT
+</para>
+<para>
+Invitations from senders which match this ACL are immediately rejected. In case
+this is an anonymous ACL then this account will not accept any invitations from
+any sender.
 </para>
 </listitem>
 <listitem>
 <para>
-detect conflict and reject or accept immediately if no conflict
+ACT_REJECT_IF_CONFLICTS
 </para>
 <para>
-detect conflict and queue or accept immediately if no conflict
+The invitation is accepted in case there is no conflict with other
+appointments and immediately rejected otherwiese. The check happens by refering
+to the uptodate free-busy list.
 </para>
 </listitem>
-</itemizedlist>
+<listitem>
+<para>
+ACT_MANUAL_IF_CONFLICTS
 </para>
 <para>
-The sender is always informed via traditional accept and reject invitation
-messages equivalent to normal non automatic invitations.
+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
+INBOX. It is expected that a user is manually maintaining the INBOX regularily.
 </para>
+</listitem>
+<listitem>
 <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
+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
+</para>
+</listitem>
+</itemizedlist>
+
+<para>
+In additon adminstrating access to resource accounts is controlled
+analogous to all other accounts with IMAP access control lists. This means
+access control lists 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.
+automatic account can be distributed like any other account in a multi-location
+setup. 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>.
+<email>Audi.A4 at erfrakon.de</email> or
+<email>group.kolab at erfrakon.de</email>.
 </para>
 </sect1>
 





More information about the commits mailing list