martin: doc/kolab-formats kolab-file-format.lyx,1.3,1.4

[cvs at intevation.de]

Author: martin

Update of /kolabrepository/doc/kolab-formats
In directory doto:/tmp/cvs-serv24876

Modified Files:
	kolab-file-format.lyx 
Log Message:
Martin: Added FAQ about Why a redundant and asymmetric format? Why TNEF in the Kolab 2.0 format?


Index: kolab-file-format.lyx
===================================================================
RCS file: /kolabrepository/doc/kolab-formats/kolab-file-format.lyx,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- kolab-file-format.lyx	30 Mar 2004 14:59:56 -0000	1.3
+++ kolab-file-format.lyx	31 Mar 2004 00:41:44 -0000	1.4
@@ -288,7 +288,7 @@
 
 \layout Standard
 
-As shown in table 
+As displayed in table 
 \begin_inset LatexCommand \prettyref{cap:Outlook-and-KDE}
 
 \end_inset 
@@ -306,11 +306,13 @@
  using an access path called the MAPI entry ID in order to refer to an object.
  MAPI knows many different MAPI storage providers including the Microsoft
  Exchange server.
+ The later can also be considered a hierarchical object store accessed via
+ MS RPC mechanisms.
  
 \layout Standard
 
-Within a MAPI object there are numerious properties similar to icalendar
- attributes.
+Within a MAPI object there are numerious properties similar but not identical
+ to icalendar attributes.
  The number of MAPI properties (
 \begin_inset Formula $M_{1}\cdots M_{m}$
 \end_inset 
@@ -358,6 +360,11 @@
 \end_inset 
 
 
+\begin_inset LatexCommand \label{-\vec{{M}}\rightarrow\vec{{N}}\rightarrow\vec{{M'}}}
+
+\end_inset 
+
+
 \layout Standard
 
 
@@ -369,7 +376,12 @@
 
 \layout Section
 
-New Kolab Storage Format
+New Kolab Storage Format (Kolab 2.0 Format)
+\begin_inset LatexCommand \label{sec:New-Kolab-Storage}
+
+\end_inset 
+
+
 \layout Standard
 
 The proposed solution to the dilemma of the non reverseable and incomplete
@@ -588,7 +600,7 @@
 
 \layout Section
 
-Future icalendar based Kolab Storage Format 
+Future icalendar based Kolab Storage Format (Kolab 3.0)
 \layout Standard
 
 With Kolab 3.0 I want to propose a new data format for Kolab based on an
@@ -597,6 +609,139 @@
  unnecessary redundancy.
  Kolab 3.0 is not subject to this paper and shall not be further discussed
  here.
+\layout Section
+
+FAQ
+\layout Subsection
+
+Why a redundant and asymmetric format
+\layout Standard
+
+The Kolab 2.0 format as described in Chapter 
+\begin_inset LatexCommand \ref{sec:New-Kolab-Storage}
+
+\end_inset 
+
+ can be described as asymmetric and redundant.
+ On a first glimpse this looks uncommon and unpleasant but on a second look
+ you will see that such a format actually solves some real issues.
+\layout Standard
+
+Due to the fact that there is no bijective mapping
+\begin_inset Foot
+collapsed false
+
+\layout Standard
+
+A mapping is called bijective if it is both injective and surjective.
+ A bijective mapping is also called a bijection.
+ A function f admits an inverse f^{-1} (i.e., f " is invertible") iff f^{-1}
+ it is bijective.Two sets X and Y are called bijective if there is a bijective
+ map from X to Y.
+ In this sense, "bijective" is a synonym for "equipollent" (or "equipotent").
+ Bijectivity is an equivalence relation on the class of sets.
+ 
+\end_inset 
+
+ between an icalendar and a MAPI object it is simply
+\emph on 
+ impossible
+\emph default 
+ to create a true symmetric storage format.
+ There will be always components within an object which only make sense
+ in MAPI.
+ Looking at the table 
+\begin_inset LatexCommand \ref{cap:Outlook-and-KDE}
+
+\end_inset 
+
+ which describes the compacted mapping you can easily see that there is
+ indeed a mapping from an icalendar object to a MAPI object possible but
+ not the reverse.
+\layout Standard
+
+This fact must lead to an unsymmetric data format for persistent objects
+ of both worlds.
+ One may for the sake of storage efficiency identify icalendar attributes
+ and MAPI properties which map bijectivly.
+ This optimization is subject to the Kolab storage format 3.0.
+ This format then presents a single syntax based on icalendar attributes
+ but requires extra icalendar attributes in order to store MAPI specific
+ data.
+ The later only gets interpreted and written by MAPI clients.
+\layout Standard
+
+The asymmetry of the problem will always be at least represented in the
+ asymmetry of the access with regards to read and write accesses or no accesses
+ at all.
+ A simple and always present example for such a MAPI property is the MAPI
+ entry id.
+ The entry id is mandatory for MAPI objects but meaningless for icalendar
+ objects.
+ If the entry id is not preserved we get the infameous duplication of messages
+ in Outlook as observed by users of early versions of the Bynari Plugin.
+\layout Subsection
+
+Why TNEF in the Kolab 2.0 format
+\layout Standard
+
+TNEF is actually not the real issue with the legacy Kolab 1.0 formated MAPI
+ objects.
+ TNEF is only an encoding defined and implemented by Microsoft in order
+ to make MAPI objects persistent and transferable via email.
+ It would definetly be possible for the Kolab Outlook Plugins to use another
+ serialization method instead of the convinient builtin TNEF encoder and
+ decoder.
+ Currently there exist several rather good and complete libraries
+\begin_inset Foot
+collapsed false
+
+\layout Standard
+
+A rather good and complete implementation of a tnef parsing library with
+ additional MAPI support is ytnef http://ytnef.sourceforge.net/.
+ This library has been designed and tested especially with Outlook calendar
+ data in mind.
+\end_inset 
+
+ which can parse TNEF encoded messages very well.
+ The difficult part is not the parsing of the TNEF encoding but the disassemblin
+g of the MAPI object into meaningful data.
+ The later requires to understand the MAPI properties and their semantics.
+ Unfortunately the MAPI object format and the corresponding MAPI properties
+ are not well documented and extremly obfusicated due to the builtin backwards
+ compatibility back to the infameous MS Exchange Email client
+\begin_inset Foot
+collapsed false
+
+\layout Standard
+
+The MS Exchange client is the predecessor of MS Outlook.
+ Please also note that MS Outlook and MS Outlook express are two distinct
+ code bases.
+\end_inset 
+
+.
+\layout Standard
+
+This leads to the need to reverse engineer the MAPI object format.
+ Fortunately the available opensource TNEF libraries ease the job of reverse
+ engineering and a simple search for unique strings in prepared MAPI objects
+ shows the relevant properties.
+ The backwards compatibility hack of the MAPI objects leads often to multiple
+ hits.
+ Using different testing patterns then reveals the correct MAPI property
+ number.
+ Sofar I could verify manually for all tested TNEF encoded MAPI calendar
+ objects that I could reveal any information required to create a complete
+ icalendar object.
+\layout Standard
+
+Due to the fact that TNEF is well supported on Windows and that TNEF encoding
+ and decoding is built into Outlook already there is no immediate gain in
+ chosing another encoding technology.
+ Therefor in order to make a robust Kolab 2.0 storage format TNEF is proposed.
+ 
 \layout Section
 
 GNU Free Documentation License