FW: New home for time zone stuff by 2012?
sm at resistor.net
Thu Aug 27 16:04:05 UTC 2009
At 07:16 27-08-2009, Olson, Arthur David (NIH/NCI) [E] wrote:
>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.
>From: Mike Douglass [mailto:douglm at rpi.edu]
>Sent: Thursday, August 27, 2009 9:56
>Possible options (as already indicated by Mr. Olson) include:
>- Moving it to an "open source" location (such as SourceForge, which has
>been already suggested)
In terms of resources, the time zone stuff needs a mailing list and a
way to distribute the database. It is better to have a party who can
ensure the long term stability of the resources.
>- Setting up some kind of open consortium of interested parties to manage
That brings some formality to the time zone stuff together with a set
of new problems depending on how the open consortium works.
>- 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).
The problem with security is that it is at odds with the "open
model". If you get into signing certificates, you have to determine
who signs the data. You invite "attacks" by with a "central"
model. It's better to leave it to the parties which interact with
the "consumers" to determine how they want to secure the time zone
data they provide.
At 08:43 27-08-2009, Robert Elz wrote:
>That's also fine - just try to concentrate on your own needs, and define just
>what you need for your purposes - don't try and solve everyone else's problems
>at the same time. Allow others to develop their own mechanisms, and
>formats. They can start with what we have, what you produce, or some other
>available format - whatever best suits their needs.
>Personally, I'd hate to see this model. I suspect that one of the real
>reasons for the success and quality of the timezone code and data is
>precisely because this model has not been followed. The code and data
>is open source in the sense that anyone can grab it, and do whatever
>with it, but it is 100% closed in the sense that there's exactly one person
>who gets to actually make the changes.
The code and data goes beyond open source. Anyone can grab it and do
whatever they like with it; they can even change the names.
>With the right person (which we've been lucky enough to have until now,
>or rather, probably until now plus the next couple of years or so) this
>works far better, faster, and more reliably, than any sorcefourge type
>solution, for this kind of (relatively small) project.
More information about the tz