bernhard at intevation.de
Mon Dec 13 17:50:29 CET 2010
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 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.
Managing Director - Owner: www.intevation.net (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format