Use of TZID in invitations (Re: Basic rationale of the KEP #2 design)

Bernhard Reiter bernhard at intevation.de
Tue Mar 15 15:24:39 CET 2011


Am Freitag, 11. März 2011 14:04:22 schrieb Georg C. F. Greve:
> On Thursday 03 March 2011 12.27:42 Bernhard Reiter wrote:
> > Can you say again why all clients need that translation table?
>
> Because the TZID in the VTIMEZONE will likely follow the system convention
> for the client sending out the invitation, and like many other clients
> we're strictly following the TZID, and not the static encoding of that
> client's interpretation and guesstimate about the future evolution of that
> time zone.
>
> For most systems, that will be Olson, but for Windows that is likely the
> Windows time zone database location. So in order to correctly interpret an
> invitation coming from a Windows system, Kontact on GNU/Linux will need to
> know which Olson location that translates into.

Ah, now I understand the argument! 
So this is about handling incoming invitations.

> P.S. And yes, this means we will not be able to handle the individually
> defined time zones which VTIMEZONE allows to invent. 

Ah, this is a good and correct observation, you are right:
If we do not save an equivalent of the data within VTIMEZONE,
we are not able to preserve the exact meaning.

One solution to the issue could be to do the calculation when we receive
the invitation according to the VTIMEZONE information and save the result,
which would mean several occurance in the case of recurring events.

Of course the other good solution is to map the VTIMEZONE to a "tz" id that
all Kolab Clients understand, which would be the Olson ids and the Olson 
definition. Assuming that the TZID of an invitation is enough to match
the table reliably enough, this can be a good solution.

And this is what non-windows clients would need the translation table for.

> The reason for this is that there is no known use case for them.

We are violating iTIP (rfc5546) by that behaviour on invitations
I guess as we would be forced to interpret the VTIMEZONE definition.
And we would be lost once there is an invitation with a TZID that does not
match the VTIMEZONE definition. We also would go wrong a lot if a client uses
a TZID in an invitation that matches the translation table, but has a widely 
differing definition coming with it.

I start to wonder now how other clients deal with these invitations. Saving 
the original VTIMEZONE data seems to be the only good way to stay compatible 
with iTIP. Maybe we should add something like an <original-vtimezone> tag
to cater for those cases? I mean all client already must have the ability to 
parse and interpret VTIMEZONE if they aim for iTIP compliance.

Georg, thanks for the post, it helped my understanding a lot.

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/20110315/40a086db/attachment.sig>


More information about the format mailing list