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

Joon Radley joon at radleys.co.za
Tue Aug 15 14:59:45 CEST 2006


Hi Martin,

> 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>.

I have no problem with the introduced encryption format for privacy, my
issue is with the key management. This is what makes the whole encryption
option fall apart. No matter how you change the format this issue will
remain.

Another fun issue will be to write an update utility for existing data
stores and in my case it is not only for Kolab.

> > > > 4. recurrances

What do you want to do with this event-list tag, extend recurrence or create
a single object to multiple object mapping?

Please ignore the other issues just concentrate on one issue at a time. Lets
evaluate the proposal from a recurrence view point.

Best regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za
  

> -----Original Message-----
> From: kolab-format-bounces at kolab.org 
> [mailto:kolab-format-bounces at kolab.org] On Behalf Of Martin Konold
> Sent: Tuesday, August 15, 2006 5:11 AM
> To: kolab-format at kolab.org
> Subject: enhanced XML Format for events (fixing recurrances 
> and allow forprivate events)
> 
> 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-annotatem
> ore-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
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format




More information about the format mailing list