Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Tony,

--On September 10, 2010 8:41:05 AM +0100 Tony Finch <dot at 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