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.
--ado
-----Original Message----- From: Mike Douglass [mailto:douglm@rpi.edu] Sent: Thursday, August 27, 2009 9:56
[snip]
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 timezone data
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.
Yes.
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.
Absolutely.
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 if needed, formats. They can start with what we have, what you produce, or some other available format - whatever best suits their needs.
Yes.
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 they like 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.
Agreed. Regards, -sm