enhanced XML Format for events (fixing recurrances and allow for private events)

Tue Aug 15 05:10:57 CEST 2006

Am Donnerstag, 10. August 2006 12:57 schrieb Joon Radley:

Hi Joon,
Hi David,

> This issue has been discussed in depth. So far the only suggestion of any
> value is the encryption option and this is not saying a lot.

With the new enhanced format is can be more easily implemented. Encrypting 
individual XML tags is cumbersome and inefficient. On the other hand 
encrypting subtrees is fine. I propose to newly introduce the tag 
<event-list>.

example pseudo xml:

<?xml version="1.1" encoding="UTF-8"?>
  < eventlist version="1.0">
        <event version="1.0">
          <uid>(string, no default)</uid>
          <body></body>
          <categories></categories>
          <creation-date>datetime</creation-date>
          <last-modification-date>datetime</last-modification-date>
          <sensitivity>private</sensitivity>
          <product-id>default</product-id>
          <summary>This is a private event</summary>
          <location></location>
          <organizer>
            <display-name>string</display-name>
            <smtp-address>string</smtp-address>
          </organizer>
          <start-date>date or datetime</start-date>
          <alarm>number</alarm>
          <show-time-as>busy</show-time-as>
          <color-label>none</color-label>
        </event>
        <event version="1.0">
           encrypted stuff
        </event>
  </ eventlist version="1.0">
</xml>

> > > 2. imap folder name translation
>
> All the default folders are already translated by the clients based on the
> Kolab XML annotation.

Currently the Kolab XML annotation is not really rich. I a lot of cases the 
client cannot know how to translate a folder correctly as this translation 
cannot be built into the client without knowledge about the individual needs 
of the users. E.g. you want to localize some non standard folders e.g. 
folders involving country names. 

For me imap folder translation is currently a low priority topic. (nice to 
have though)

I propose to discuss the topic of folder annotations in an extra thread.

> What other folders do you want to translate? Also 
> what process will be doing the translation, client, server, user or
> administrator?

I an thinking that the translation should be done by a human and stored in 
IMAP METADATA (this extension is currently not fully implemented for Cyrus 
IMAPd). I am expecting a patch within the next two months though.

see also: 
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-09.txt

> > > 3. priority specification
>
> The issue was last left at the loss of priority when it hits a Outlook
> object. I am still waiting for a response as to what loss will be
> acceptable.

I propose to discuss this in an extra thread.

> > > 4. recurrances

> Firstly the Outlook recurrence object changes from version to version as do
> the support for what recurrences are supported.

Yes, imho the OL connectors need to adapt for every new version of OL anyway. 
On the other hand we need an XML format which is _able_ to express the 
already available options while allowing with some probability to also remain 
usable for unknown future version of OL. 

The currently defined Kolab XML format for events is definetly _not_ able to 
express all capabilites of OL. This leads to interoperability problems loss 
off data / incorrect data as soon the data did an XML roundtrip e.g. 
ol->s->kontact->s->ol.

> Secondly due to the nature of recurrences and exceptions, the definition of
> rules can become very complicated. It will take a lot of effort to define
> the rules and then some more to make them work with all the clients.

The idea is that the xml format shall allow a lossless representation of the 
OL definition. IMHO it is mandatory that the xml format shall not be the 
limiting factor.

> > allow not only for one event tag in the
> > application/x-vnd.kolab.event but an
> > ordered list of multiple events.
>
> So from what I understand you want to have one object on the client and
> multiple objects on the server. They are then all linked via the
> application/x-vnd.kolab.event tag set on each of the objects on the server.
> I can only assume that all the objects will be in the same folder and that
> each object will have to contain the tags of all the other related objects.

Not really. I am thinking about a newly introduced <event-list> tag. This 
means a single object on the server in the form of a single email mime 
attachment containing a single xml document, containing a single 
<event-list>, containing an ordered list of potentially multiple 
<event></event> pairs.

> Could you please provide the synchronization logic for this scheme between
> the client and the server.

The synchronization logic is as follows:

s->c:

1. Parse the first <event></event> pair in the <event-list>. E.g. the first 
event describes a recurring event (every wednesday) with the exception of 
oct. 4th

2. Create an intermediate OL event object and fill in the data retrieved from 
the first <event></event> pair.

3. Parse the next <event></event> pair in the <event-list>

4. Put the retrieved information e.g. another time for the recurring event on 
oct. 4th.... in the already existing OL event object. (something like 
an "ordered or" operation)

5. Repeat step 3 and 4 until the end of <event-list>

c->s:

1. Create the xml document <xml> and the <event-list>

2. Parse the OL object and create the first <event> putting as much 
information as possible in this event. Add exceptions for all those dates you 
cannot express in this event. E.g. different attendendies, a different time 
or a different location.

3. For each exception add an extra event in the xml document containg only the 
_extra_ information. 

4. Close the xml document </xml>

Joon: What do you think?

David: How to implement something like this in a backwards compatible way?
       Which proposed format are you prefering?
       What about KDE Kontact?

Is it a better idea to introduce a less clean but more backwards compatible 
format?

<xml> <-! example for an event with exceptions ->
    <event>
      legacy kolab xml format for backwards compatibility describing the event
      and its exceptions as good as possible
      <eventlist version="1.0"> 
          <eventlist-entry>  <-! ignored by legacy Kolab clients ->
             the syntax equivalent of <eventlist-entry> is equivalent to
             <event> but not all features are currently used. E.g.
             we don't use exceptions of exceptions.
          </eventlist-entry> <-! ignored by legacy Kolab clients ->
          <eventlist-entry>  <-! ignored by legacy Kolab clients ->
          </eventlist-entry> <-! ignored by legacy Kolab clients ->
          <eventlist-entry>  <-! ignored by legacy Kolab clients ->
          </eventlist-entry> <-! ignored by legacy Kolab clients ->
      </ eventlist version="1.0">
  </event>
<xml>

<xml> <-! example for a private event ->
    <event>
      legacy kolab xml format for backwards compatibility describing the
      public data of an event e.g. begin/end date
      <eventlist version="1.0"> 
          <eventlist-entry>  <-! ignored by legacy Kolab clients ->
             encrypted private data e.g. participants, locations, summary
          </eventlist-entry> <-! ignored by legacy Kolab clients ->
      </ eventlist version="1.0">
  </event>
<xml>

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker