| From: Mike Douglass [mailto:douglm@rpi.edu] | Sent: Thursday, August 27, 2009 9:56 | To: tz@lecserver.nci.nih.gov | Subject: RE: New home for time zone stuff by 2012? | 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. That sounds fine, though (other than to the group of people with a direct reason to really want to stay up to date) I'm not sure it will have much impact upon the vast majority of nodes. | 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. 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. | CalConnect would like to see a formal "standardization" of timezone names | with a registry. We have standard names already, and a registry - the only real problem we have (aside from governments who won't allow almost anything to remain stable in this area) is that people keep wanting to disagree about the actual names. That's the least productive of everything that happens here, name choice is a hideously non technical area, where most of the arguments are derived from politics, religion, and vanity [*], rather than anything with any substantive rationale. If you want get into that, please do - just don't do it here, or (and I perhaps shouldn't speak for everyone else here, but I will) anywhere near the rest of us. | 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. I have no idea what names you're using (or if perhaps the problems are more related to versioning than naming), but if you just used the tzdata names then (versioning issues aside) you would have no more technical problems with the names (though you're going to have plenty of social problems). | Possible options (as already indicated by Mr. Olson) include: | | - Moving it to an "open source" location (such as SourceForge, which has | been already suggested) 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. 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. | - Setting up some kind of open consortium of interested parties to manage | timezone data The data isn't open to debate (or shouldn't be), we don't need a consortium to manage it - what we could do with is better communication channels to and from the people who actually make the changes, so that we can record them correctly, and in a more timely fashion than we currently sometimes manage. | - 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) I doubt either of those is needed. Remember we are not creating anything new, we're just attempting to document what others have done, or what (in some cases) it seems they are about to do. | 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 ... but as long as we insist on the data remaining available to all (which is not hard, as anyone who would attempt to restrict it can simply be ignored, and someone else just continues from the last public version, plus updates), the control issue can be not so much of a problem. If we ever start worrying about money for this, then we have really failed. I can't speak for ado, obviously, but it is hard to imagine the process of looking after this stuff (perhaps the mailing list aside) consuming more than 15 or 20 minutes a week (on average, there are busy and quiet periods.) Since our "customers" are fairly limited, the traffic involved in distributing the data to those who need to get it directly from the source (rather than via an OS update, or similar, or whatever you are planning) should be, and remain, basically negligible. And anyone can contribute, of course - but all we want is authenticated facts (this is for the data which is what matters most, we're perhaps already just about reaching the point where maintaining the code is not so necessary any more - others can do that, in their formats for their own systems, we no longer really need to provide free code just to convince people that it is cost effective to use this data.) | 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. Yes, we (it seems) might need a change of czar, but ideally that's about all we need to be changing. | 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). That seems reasonable, and fairly easy. | This may very well impose additional | requirements on hosting the data in the future, e.g., cost of | maintaining the server, signing certificates etc). I sincerely hope the server cost never becomes an issue. We don't need costly certificates for this - or rather, we don't need one of the ones that you would buy from a public certificate authority - those have their uses, this is not one. After all, the only things that are needed to make a CA, are trust, and stability - it needs to be trusted by all of its users, and stable enough not to require changes to its keys. For our purposes, we have (and should keep on having) relatively few consumers - all we need is for all of them to trust us (whoever is the czar) and the published public key. As long as everyone "knows" what that key is, it is essentially impossible for anyone to subvert (ignoring attacks that attempt to discover the private key). That's the same principle that the "big" CA's operate on, except that they need to deal with very large numbers of unknown consumers, so they have more work to do, ours is a simpler task. So, we just need a key pair, keep the private key secure, and widely publish (amongst the community that cares) the public key, use that key to sign a certificate, and use the key in that certificate to sign the date distributions (two levels as the actual key that's in use cannot be kept as secure - it needs to be available to sign updates, so is more vulnerable). Cost - about half an hour of someone's time to set up, and essentially nothing thereafter.) kre ps: an off-list message suggested a couple of possible people, one of whom was me, as possible successors to ado - while I'm flattered by the suggestion, and would be willing, I would not make a good choice, as we (you) would probably just have to repeat the process again far too soon, I am also not that far away from retiring age (sometime next decade at least I would expect.) [*]: politics - making decisions based upon what will most cause other people to prefer you, rather than some other guy religion - making decisions based upon no better justification than that someone said it was so, therefore it must be so, and is not debatable vanity - making decisions in order that you see yourself as having been more important / better / ... than everyone else