[Ietf-calsify] Re: What's wrong with more radical simplification?

[Helge Hess]

On 11. Feb 2005, at 21:12 Uhr, Michiel van Leeuwen wrote:
> Let's assume that timezones move to an extension. The client i use 
> supports them. So, the start time of en event is defined with a 
> timezone.

No, the start time would still be defined in UTC, the timezone would be 
added as a hint (actually a required one for the rrules extension).

> I publish the calendar. (upload the whole ics file). Someone else 
> reads it using a client that doesn't support timezones. How can he 
> fall back?

See above, the times will always be in UTC, the timezone is additional 
information. So its a non-issue.

> he has to ignore the timezone information, because he doesn't 
> understand it.

Yes, and it won't hurt since the time value is always in UTC, there is 
no reason to do it otherwise. We only transport timezone information to
a) add information for editors/viewers
b) to allow for rrules

You seem to miss the reasons when and why timezones are required in the 
protocol/format? I'm somewhat surprised about that, since exactly this 
was discussed only some weeks ago including some details on how this 
could be done format-wise.

> He can either use the time in the wrong timezone, or ignore the time 
> completely. Both is wrong.

Yes, because your assumptions is wrong. To be up/downwards compatible 
timevalues would always be in UTC.

> So, if i want my calendar to be readable by other clients, i can't use 
> timezones.
> The same story would hold for other extensions.

Of course extensions must be properly done to be compatible, but so far 
both discussed items can be easily done as extensions while still 
providing downwards compatibility AND provide the same functionality 
like before.


BTW: we do not talk about timezone awareness in the client, this has to 
be available in any case. This is only about including timezone 
information in the protocol entity which is only required for 
recurrences and to one kind of allday appointments (as far as I can 
see).

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org