Re: [calsify] [Tzdist-bis] tzdist and IANA

[Paul Eggert <[e-mail]>]

Here are some other thoughts about any potential IANA effort in this area:

* As others have mentioned, the effort should address authentication of the 
timezone data. It would be helpful to have a real authentication expert in on 
this, since we want something simple and scalable and workable downstream (see 
below).

* Each tzdb release comes with a version number like "2019b", development 
commits have version numbers like "2019b-11-gd8c6bf2". Downstream publishers 
often make minor changes to the data, and some append a suffix to the version 
number to indicate this. The mechanism for publishing this number is specified 
only loosely in Internet RFC 7808 section 3.10, and presumably the IANA effort 
would do something more specific. Downstream modifications will complicate data 
authentication.

* Each tzdb release has auxiliary metadata files zone1970.tab and iso3166.tab 
that contain vague geographical information associated with each tzdb entry. (In 
some cases this vagueness is intentional, to avoid running into political 
disputes.) These files are not covered by TZDIST but some POSIX-style clients 
use them. How should metadata like this be addressed?

* Each tzdb release has an auxiliary data file 'leapseconds' that is widely used 
by clients running NTP and related software. TZDIST has a "leapseconds" action 
that conveys the information in a different format, and we would need to make 
sure that this all hooks up correctly.

* It'd be helpful to support not only TZDIST, but also a reasonably simple 
protocol, presumably based on HTTPS transfer of the data since HTTPS is widely 
supported. This could be used by platforms that don't support TZDIST, or that 
need auxiliary metadata that is outside the scope of TZDIST. For example, many 
NTP hosts need a 'leapseconds' file but don't support TZDIST or grok its leap 
seconds data format.