KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)

Bernhard Reiter 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. ;)

Best,
Bernhard


-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101214/6282ee46/attachment.sig>


More information about the format mailing list