[tz] Proposal: validation text file with releases

[Steffen Nurpmeso]

Tim Parenti <tim at timtimeonline.com> wrote:
 |On 15 July 2015 at 08:45, Steffen Nurpmeso <sdaoden at 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