Hi Tony,
--On September 10, 2010 8:41:05 AM +0100 Tony Finch <d...@dotat.at> wrote:
If you have a beef with the iCalendar data model, feel free to try to
come up with a better one.
Funny you should say that :-)
http://fanf.livejournal.com/104586.html
That is a beef about timezones - one piece of iCalendar, but my no means
all of it.
I disagree with your suggestion of using a location to represent a timezone
- there are a number of reasons why that won't work - not least that many
events often do not have a physical location associated with them.
That said work is going on to move to a "timezone by reference" rather than
"timezone by value" model for iCalendar. There are many driving forces
behind that, including several of the points you mention, plus the fact
that often times the timezone definition included in iCalendar data is
larger than (character-wise) then the actual event information, wasting
bandwidth.
To that end several options are being proposed. We have already posted a
draft for a generic timezone service
(<https://datatracker.ietf.org/doc/draft-douglass-timezone-service/>) - a
server that can be queried for timezone definitions based on standard IDs
(Olson identifiers). This allows clients and servers to get timely updates
to timezone information (rather than having to wait for the next OS
upgrade). We are working on defining how "timezone by reference" will work
with the CalDAV calendar access protocol (RFC4791). Since that uses HTTP,
simple client/server negotiation options exist to facilitate that.
Note that the timezone service is not intended to just be used by iCalendar
related tools - but we expect/hope that any device that needs to cache
timezone definitions (e.g. unix zoneinfo data) can also make use of that.
Best place to continue this particular aspect of the discussion would be
the ietf-calsify WG mailing list.
--
Cyrus Daboo
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
