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

[Bernhard Reiter]

Am Montag, 21. März 2011 13:21:49 schrieb Georg C. F. Greve:
> On Tuesday 15 March 2011 15.24:39 Bernhard Reiter wrote:
> > I start to wonder now how other clients deal with these invitations.
>
> I think the first question is whether such invitations actually exist.
>
> Most clients seem to allow users to select from existing, real time zones,
> and I have not yet seen clients which allow users to define arbitrary time
> zones on top of the existing ones - probably because this is not an often
> requested feature.
>
> *IF* such a thing exists, I'd be glad for pointers.

I agree that this is the right question. It would also be interesting
how other clients like Outlook would deal with the situation.

Note that it could well be the case that the TZID of iTIP just is
an arbitrary string, but the corresponding VTIMEZONE definition
matches a real timezone. However doing this match probably is untrivial,
so it would be hard to detect.

> > 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.
>
> The question is whether we're catering to an actual use case, or just
> introducing bulk for no gain. In the end, if we decided to cater to static
> storage of time zone information, the better approach would probably be to
> do this in the form of an explicit cache, which is filled by the initial
> VTIMEZONE data, and only updated if clients know/recognize the time zone.
>
> Otherwise the time zone ID could be set to a special value, e.g. "CUSTOM".

I agree with both points about if in-format tz-data would to be used.
My <original-vtimezone> tag was meant to be such a CUSTOM block.

> But as I said before, first I'd like to know whether there is an actual use
> case for this in the wild.

Being able to claim full iTIP compliance certainly is a small usecase for 
Kolab marketing. :) But you are fully right in that this would need checking.

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/20110322/972d59df/attachment.sig>