KEP2

[Hendrik Helwich]

Hi Bernhard,

Am Montag, 13. Dezember 2010 17:50:29 schrieb Bernhard Reiter:
> Henrik, All,
> I am still reading my way through this large discussion. Here is are two
> points I already can make:
>
> Am Donnerstag, 9. Dezember 2010 11:08:52 schrieb Hendrik Helwich:
> > I do not understand, why the first bullet now states "All clients
> > MUST parse datetime fields according to RFC3339", as there is absolutely
> > no need to make this an requirement due to the fact that all datetime
> > fields are written in Zulu-format according to the second and third
> > bullet (as of KEP2 rev. 10707, 2010-12-06) discussed above.
> > I would fully understand and support writing "Clients MAY parse datetime
> > fields according to RFC3339" and putting that point further down in the
> > bullet list,
>
> If we want to allow for tolerance here, we would have to declare it to be
> mandatory, otherwise clients could not rely on it and it would be useless.
> Tolerance can be good to support old non-conforming client or future uses.
> Georg's proposal is consistent in this regard.

As i understand supporting non-conforming old clients is not necessary for the 
Kolab format 1.1.
Future violations of format 1.1 by kolab clients could not be foreseen right 
now.
IMO it is better to be strict and and offer an easy validation possibility.
An XML Schema could be added to the 1.1 specification so that it can easily be 
tested if a kolab client writes valid kolab xml.
This could be also very helpful for kolab client implementors.

Best regards,

Hendrik

> As the problem we are trying to solve actually comes only from recurrent
> objects from tasks and events. One idea I have is: What about we make a
> change to the format that only newly written tasks and events that include
> recurrence MAY use the new format?
> Newly written means a new or changed event. This way new clients
> would stay mostly compatible with already existing ones.
>
> Best,
> Bernhard