FW: New home for time zone stuff by 2012?

[Olson, Arthur David (NIH/NCI) [E]]

I'm forwarding this message from Mike Douglass, who is on the time zone mailing list now but was not when the message was sent.

				--ado

-----Original Message-----
From: Mike Douglass [mailto:douglm at rpi.edu] 
Sent: Thursday, August 27, 2009 9:56
To: tz at lecserver.nci.nih.gov
Subject: RE: New home for time zone stuff by 2012?

The Calendaring and Scheduling Consortium (CalConnect), through a number
of activities over time, has demonstrated an active interest in
addressing problems related to timezones for calendaring and scheduling
systems for a while. The standards in this space, namely iCalendar, were
developed by the Internet Engineering Task Force (IETF).  A number of
issues have spurred this work within CalConnect, including (but not
limited to) the US EDST changes from 2007.

As "consumers" of timezone data (rather than "producers" - which relates
to the job done by the community represented by this mailing list,
tz at elsie.nci.nih.gov) we are eager to see a reliable, timely and secure
process for handling timezones.  

In CalConnect's Timezone Technical Committee (TC), we are presently
developing a timezone service protocol that will allow for direct updates 
of client systems, rather than relying on the current process where
systems typically get updated via OS upgrades, if at all. As part of this 
effort, we are also developing a generic timezone description format in
XML so that interchange of timezone data can be done efficiently, and so
that we can include structured meta-data like KML for boundary information.

CalConnect would like to see a formal "standardization" of timezone names 
with a registry. This issue has been a problem in the iCalendar space
where presently it is difficult to rely on a timezone definition with a
given name, often resulting in interoperability problems. CalConnect
would like to see timezone data passed "by reference" rather than "by
value" for efficiency purposes (iCalendar requires that a VTIMEZONE
component always be included in the iCalendar data stream when a timezone 
is referenced by an event).

Earlier this year, CalConnect hosted a timezone workshop at one of its
face-to-face Roundtables. The primary focus of the workshop was to
discuss the problem statement and development of the protocol, data
format and registry process. Since then we have also initiated
discussions in the IETF on these topics.

As "consumers" of timezone data CalConnect feels strongly about the need
for these improvements. None of this necessarily impacts the process of
"producing" timezone data as carried out by this list's community.
Nonetheless, we care greatly about the "production" process because we
have to rely on this data.

We have informally discussed within the CalConnect Timezone TC what we
would like to see for the future of the timezone data. We have not come
to any firm conclusions as to the best way forward. Mr. Olson's email,
therefore, comes as a timely reminder that this needs to be addressed now.

Possible options (as already indicated by Mr. Olson) include:

- Moving it to an "open source" location (such as SourceForge, which has
been already suggested)
- Setting up some kind of open consortium of interested parties to manage 
timezone data
- Moving responsibility to an existing standards body (e.g., the IETF or
the Internet Society - ISOC)
- Moving responsibility to a government entity (e.g., the UN)

Unfortunately, this debate can easily get mired in "politics" rather than 
technical issues. e.g., who gets to control the data, how is the service
paid for, who gets to contribute.

At the end of the day, CalConnect favors an approach which results in the 
least amount of disruption. The open community process developed via this 
list's community has clearly been a success, and should be considered as
a potential model going forward.

CalConnect considers tightening up of the security of the timezone data
to be essential. Given that many systems rely on the data being produced, 
we collectively need a secure distribution (i.e. a secure, reliable
server, signed data etc). Whilst there have not been any obvious
"attacks" against timezone data, one cannot assume there won't be any in
the future. This is a propitious time to achieve consensus on the best
way to    secure the data. This may very well impose additional
requirements on hosting the data in  the future, e.g., cost of
maintaining the server, signing certificates etc).

CalConnect looks forward to the discussions on this issue, and would like 
to hear the thoughts of other members of this community. CalConnect is
ready to host another face-to-face timezone workshop, open to all
interested parties, at our member meeting in February 2010. 


Mike Douglass                           douglm at rpi.edu
Chair Timezone Technical Committee, on behalf of CalConnect