Tim Parenti <tim@timtimeonline.com> wrote: |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 Ah, (oh,) i am not on this list, i only have read the draft once that came up on the leapsecond list (version -05). I never used any TZ code (we had a single large DB, but with the possibility to include one (see how weird) timezone in the library binary), and if you would ask me then i don't think that including anything zic is a good option (but don't dig deeper here). I would simply take the developed TZDIST protocol and instead of GET /capabilities HTTP/1.1 Host: tz.example.com
Response <<
HTTP/1.1 200 OK Date: Wed, 4 Jun 2008 09:32:12 GMT Content-Type: application/json; charset="utf-8" Content-Length: xxxx i'd return HTTP/1.1 200 OK Date: Wed, 4 Jun 2008 09:32:12 GMT Content-Type: application/cbor; charset=binary Content-Length: xxxx which should be the most simple and cheap and 1:1 possibility on the server and the client side. This is what CBOR is for, among others. |ยง4.1.2 of the latest draft (draft-ietf-tzdist-service-09) says |<https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-4.1.2> |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. Yes; but like i said, why reinventing the wheel if there is a standardized, very easy to parse (i really like it, it is rocking) binary format that is capable to interact 1:1 with the JSON that is used by the upcoming TZDIST standard? That would be my thought on that. Because JSON is still too expensive especially if the cost is for nothing at all (and if you want to present data to the user you can still do a mapping easily). --steffen