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

[Hendrik Helwich]

Hi Bernhard,

Am Dienstag, 14. Dezember 2010 12:26:20 schrieb Bernhard Reiter:
> 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.

i get confused with the kolab format versions here. What you referred as 
2.0 (the old format) is sometimes called 1.0 here.
I think it is because the specification has the version 2.0rc7 right now but 
it specifies to write the version "1.0" to the kolab xml.
So how should we call the two versions to not get confused on this list?

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

It can make sense on most platforms but the specification should not request 
this because it depends on the implementation.
And even if it is requested it should be done in the old format specification 
and not in the KEP 2 because the issue of backward compatibility only occurs 
with the old format.

I wanted to point out that the first and third bullet point in KEP 2 should be 
made more clear IMO. It is misleading and unnecessarily complex to define 
different formattings for reading and writing the format. Instead it should 
only be constrained how the datetime type must be formatted in the kolab xml. 
How this is achieved is the responsibility of implementing.
Also the second bullet point is refined by the third bullet point. So the 
three points could be summarized to one point.

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

I know no other client.

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

That would be even more error-prone.

Best regards,

Hendrik

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