KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)
bernhard at intevation.de
Tue Dec 14 12:26:20 CET 2010
Am Dienstag, 14. Dezember 2010 11:03:23 schrieb Hendrik Helwich:
> for the current Kolab format 1.0 i would say it is necessary to be able to
> parse RFC3339 datetimes to not lock out kolab clients which are not conform
> with the specification. It is certainly a good idea to use a RFC3339
> library here.
To me you are essentially saying by this that all clients
would need RFC3339 parsing code, because for practical reasons
I think that all clients will need to understand the 2.0 format
for a while and for interoperability reasons.
> But for the Kolab format 1.1 we have the chance to be more strict in the
> definition and the parsing of the Kolab format.
> The KEP2 document says that the datetime types *must* be written in the
> Zulu format.
> Why should clients than be forced to use a RFC3339 library if it is not
> needed and the use of a system library would also be possible?
To me this looks less practical as all clients will
have such a library anyway, if we go by your above suggestion.
> Also the problem that we have right now with the datetime type, results
> from the fact that some Kolab clients are using a RFC3339 library in a way
> that breaks the Kolab 1.0 format.
As posted before: There seems to be one broken Kontact client, which will
get fixed. The revisions affected as far as I can see now were never a Kolab
Client recommended for production. So they can be considered development
versions which can have defects and they will get updates.
So which other clients are we talking about?
> So it is rather a disadvantage in a kolab client implementation to use a
> RFC3339 library if it is not needed and it should not be constrained in the
> specification in my opinion.
You could roll your own parsing code.
> Also i think the specification should concentrate on the format constraints
> and should not make implementation constraints if they are not needed.
To be able to get a consistant Kolab Client behavior, we will have make
constraints for the behaviour of the client itself, which includes
presentation to the user. Yes we would better need a
Client Implementors Manual. Being short of it, the format descriptions and
reference clients are the best we have. ;)
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