[Kolab-devel] doc/architecture client_client.sgml,1.4,1.5 client_server.sgml,1.6,1.7 overview.sgml,1.4,1.5 by bernhard at doto.intevation.de

[root at intevation.de]

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

Modified Files:
	client_client.sgml client_server.sgml overview.sgml 
Log Message:
Subtituted iCalendar for vCal.
Fixed a typo and added a missing space at some place.


Index: client_client.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_client.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- client_client.sgml	5 May 2003 22:35:39 -0000	1.4
+++ client_client.sgml	24 Jul 2003 17:24:18 -0000	1.5
@@ -22,7 +22,7 @@
 
 <sect1><title> Group Event Notifications </title>
 <para>Invitations to a group event are sent via a multi-part MIME email with
-vCal information
+iCalendar information
 included as a MIME part. The user can decide to either accept the event (and
 thereby
 import it into his own calendar) or decline it. When an event is declined, an 
@@ -37,7 +37,7 @@
 communicating with a legacy
 Windows Outlook/Bynari client. In this case calendar events are sent as plain
 MIME email with
-the vCal data being the body of the email. This non RFC-conformant mode is not
+the iCalendar data being the body of the email. This non RFC-conformant mode is not
 recommended by the
 IETF but the only way to communicate with broken Windows clients. In fact the
 KDE client can
@@ -58,7 +58,7 @@
 Step</entry><entry>Action</entry><entry>Remarks</entry></row></thead>
 <tbody><row>
 <entry><para> 1 </para></entry>
-<entry><para>Originator sends Email with attached vCal to
+<entry><para>Originator sends Email with attached iCalendar to
 attendees</para></entry>
 <entry><para>Calendar event gets saved in originator's own 
 calendar</para></entry>
@@ -76,7 +76,7 @@
 <entry><para>
 Attendee A accepts the event and sends back a confirmation; attached is the 
 slightly
-modified vCal (attributes used: DTSTAMP and ATTENDEE)</para></entry>
+modified iCalendar (attributes used: DTSTAMP and ATTENDEE)</para></entry>
 <entry><para>Calendar event gets saved in attendee A's calendar (subset of 
 original event including
 participants; only originator has full information e.g. the state of
@@ -84,7 +84,7 @@
 </row>
 <row>
 <entry><para> 3b </para></entry>
-<entry><para> Originator gets email with the  slightly modified vCal 
+<entry><para> Originator gets email with the  slightly modified iCalendar 
 attached</para></entry>
 <entry><para> Originator learns about the update and refreshes the event in his 
 calendar
@@ -94,13 +94,13 @@
 <entry><para> 3c </para></entry>
 <entry><para> Attendee B declines the event and sends back a refusal; attached 
 is the
-slightly modified vCal (attributes used: DTSTAMP and ATTENDEE)</para></entry>
+slightly modified iCalendar (attributes used: DTSTAMP and ATTENDEE)</para></entry>
 <entry><para>Calendar event is not saved into attendee B's 
 calendar</para></entry>
 </row>
 <row>
 <entry><para> 3d </para></entry>
-<entry><para> Originator gets email with the  slightly modified vCal attached 
+<entry><para> Originator gets email with the  slightly modified iCalendar attached 
 </para></entry>
 <entry><para> Originator learns about the update and refreshes the event in his 
 calendar
@@ -127,13 +127,13 @@
 In the originator's calendar the state of the attendees therefore gets reset. By 
 
 having a unique
-message ID it is guaranteed that the vCal matches again to the same calendar 
+message ID it is guaranteed that the iCalendar matches again to the same calendar 
 event. This guarantees
 that a calendar event can be shifted without ending up to be created multiple 
 times.
 When new attendees are added or some are deleted, the originator gets prompted
 on whether
-the notification (again a vCal entry) should be send to all people involved or 
+the notification (again a iCalendar entry) should be send to all people involved or 
 only to those who
 are actually affected by the change.</para>
 </sect3>
@@ -155,7 +155,7 @@
 event before issuing the actual invitation. Therewith a meeting can be scheduled
 more efficiently and according to the attendee's free time slots.</para>
 
-<para> A free-busy file follows the vCal format and contains only the calendar
+<para> A free-busy file follows the iCalendar format and contains only the calendar
 event time data for a given user.
 The user can choose how long into the future his free-busy information should be
 published on the Kolab server. On the Kolab server all free-busy data is stored
@@ -184,12 +184,11 @@
 so this does not necessarily mean an overhead  </para></entry>
 </row><row>
 <entry><para> 2  </para></entry>
-<entry><para> Compute a consolidated vCalendar based on the vCal data
+<entry><para> Compute a consolidated iCalendar based on the individual iCalendard data files
 </para></entry>
-<entry><para> a collection of vCal data is called vCalendar </para></entry>
 </row><row>
 <entry><para> 3 </para></entry>
-<entry><para> Publish the vCalendar free-busy list on the Kolab server
+<entry><para> Publish the iCalendar free-busy list on the Kolab server
 </para></entry>
 <entry><para> This is preferably done using Web-DAV via HTTPS;
 Windows clients use anonymous FTP and retrieve via HTTP (Kolab legacy mode)
@@ -354,7 +353,7 @@
 <sect1><title> Multi-User Task Lists </title>
 <para>A task can be send to other users via a multi-part MIME email. The task 
 list is represented by a MIME
-part containing a vCal (vToDo). For sending tasks to Windows clients a special 
+part containing a iCalendar (vToDo). For sending tasks to Windows clients a special 
 legacy format must be
 readable and writeable by the KDE client.
 See the appendix for the exact file format.</para>

Index: client_server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_server.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- client_server.sgml	5 May 2003 22:35:39 -0000	1.6
+++ client_server.sgml	24 Jul 2003 17:24:18 -0000	1.7
@@ -42,7 +42,7 @@
 <itemizedlist>
 <listitem><para> multi-part MIME email as standardized by the IETF 
 </para></listitem>
-<listitem><para> vCal 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>
@@ -146,25 +146,25 @@
 Kolab server. Physically they are represented as multi-part MIME emails with the 
 
 information stored
-in vCal format encapsulated in a MIME part.
+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 vCal
+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.
-The individual free-busy lists consist of a compacted subsets of the vCal 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.
 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 vCal file format.</para>
+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
@@ -201,7 +201,7 @@
 Physically, they are multi-part MIME emails with the actual task list data being 
 
 a MIME part and
-following the vCal standard (vToDo, IETF RFC 2446).
+following the iCalendar standard (vToDo, IETF RFC 2446).
 See the appendix for the exact file format. </para>
 </sect1>
 

Index: overview.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/overview.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- overview.sgml	5 Jun 2003 06:19:39 -0000	1.4
+++ overview.sgml	24 Jul 2003 17:24:18 -0000	1.5
@@ -52,7 +52,8 @@
 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 
-directory on the Kolab server and can beexported to vCal format. The necessary 
+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 
 change his personal contact information on the Kolab server by using a web 
 interface.</para></sect1>
@@ -60,7 +61,8 @@
 <sect1><title> Calendar Entries </title>
 <para>A user can have private calendar events. Although these events are visible 
 for other users,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 
+that a given private event of another user exists. 
+Private events are saved on 
 the Kolab server.Users can schedule group events and invite other users. An 
 existing group event can be modifiedby the user who originally created it. 
 Examples for group events are:<itemizedlist>