FW: New home for time zone stuff by 2012?

[Robert Elz]

  | 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?

  | 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