On 15 July 2015 at 08:45, Steffen Nurpmeso <sdaoden@yandex.com> wrote:
What would be an issue to me is instead that TZDIST doesn't offer
a binary representation but only (iCalendar,) JSON and XML, which
require parser libraries, whereas with CBOR the IETF standardizes
a wonderful, extensible and otherwise future-proof binary format
that also has been designed with easy JSON mapping in my mind.

Not that this should become a tzdist discussion, but it is my understanding that tzdist has left the distribution of compiled binaries for zones to future work.  In particular, this would require writing up a spec describing the binaries compiled by zic.  Certainly not insurmountable, but also not a priority at this time.

http://www.ietf.org/mail-archive/web/tzdist/current/msg01207.html
http://www.ietf.org/mail-archive/web/tzdist/current/msg01218.html

§4.1.2 of the latest draft (draft-ietf-tzdist-service-09) says that "Clients use the HTTP Accept header field (see Section 5.3.2 of [RFC7231]) to indicate their preference for the returned data format.  Servers indicate the available formats that they support via the 'capabilities' action response (Section 5.1)."  So, as I understand it, there's definitely room for tzdist implementations to support this even without the file format being formalized.

--
Tim Parenti