W3C home > Mailing lists > Public > www-rdf-calendar@w3.org > February 2005

Re: [Ietf-calsify] Re: Google Speculation, but interesting

From: Doug Royer <Doug@Royer.com>
Date: Sun, 27 Feb 2005 12:45:30 -0700
Message-ID: <4222235A.2040801@Royer.com>
To: Calsify <ietf-calsify@osafoundation.org>, www-rdf-calendar@w3.org

Sending static timezone information is a short term solution.
The real problem is access to the latest accurate information.

It does not matter if the VTIMEZONE (or RDF) data you sent to me
six months ago for next months meeting  was accurate at that time.
It matters that we both expect a meeting to start at the same time.

The TZ (they asked me to stop calling it Olson database) database
is the most accurate and kept up database that I can find.
However iCalendar applications already know how to parse
VTIMEZONE data, so my IETF proposal is to sync that TZ database
at IANA and make the latest information available in iCalendar
format. It includes revision information so you can tell
if you have the latest TZ data or not.

I see no reason that IANA could not also create RDF data
at the same time and keep everyone in sync.

The biggest issue might be if everyone goes totally dynamic, the
download load on IANA (or whoever) could go sky high. So
there needs to be some kind of consideration or plan for
sharing the load to regional or vendor servers. (Or not?)

And a simple 'what is the latest rev date on the XXX timezone'
binary protocol needs to be developed. And only then download
the 'latest' VTIMEZONE or RDF data when you are out of sync.

Only then can we stop sending static VTIMEZONE information
for each and every calendar data object transferred.


-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards





Received on Monday, 28 February 2005 03:21:51 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:20:45 GMT