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

Lester Caine <lester@lsces.co.uk> Thu, 18 July 2019 09:01 UTC

Return-Path: <lester@lsces.co.uk>
X-Original-To: tzdist-bis@ietfa.amsl.com
Delivered-To: tzdist-bis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0822812016E for <tzdist-bis@ietfa.amsl.com>; Thu, 18 Jul 2019 02:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUe2-coeWC2L for <tzdist-bis@ietfa.amsl.com>; Thu, 18 Jul 2019 02:01:11 -0700 (PDT)
Received: from mail4.serversure.net (mail4.serversure.net [185.153.204.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE2012016D for <tzdist-bis@ietf.org>; Thu, 18 Jul 2019 02:01:11 -0700 (PDT)
Received: (qmail 11628 invoked by uid 89); 18 Jul 2019 09:01:07 -0000
Received: by simscan 1.3.1 ppid: 11596, pid: 11624, t: 0.0407s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677
Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@87.75.107.50) by mail4.serversure.net with ESMTPA; 18 Jul 2019 09:01:07 -0000
To: tzdist-bis@ietf.org
References: <CADZyTkkNuenOTx77cB8vFzWaSjp_fqtEgaYd00t5e2+Kk6MtRA@mail.gmail.com> <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <CADZyTkms=skOgqfoDxTF6TSZBsWbfaCmfPBWCG0E9qb4-qA0Uw@mail.gmail.com> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com>
From: Lester Caine <lester@lsces.co.uk>
Message-ID: <38d057df-0c86-2c2f-35e6-b109f4f448d3@lsces.co.uk>
Date: Thu, 18 Jul 2019 10:00:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tzdist-bis/gXaz0gjOBDRloqZ9wJSWUj22xXY>
Subject: Re: [Tzdist-bis] [calsify] tzdist and IANA
X-BeenThere: tzdist-bis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Extensions to Time Zone Data Distribution Service <tzdist-bis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist-bis>, <mailto:tzdist-bis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tzdist-bis/>
List-Post: <mailto:tzdist-bis@ietf.org>
List-Help: <mailto:tzdist-bis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist-bis>, <mailto:tzdist-bis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2019 09:01:14 -0000

On 18/07/2019 07:02, Eliot Lear wrote:
> While the IANA does a great job at servicing our assigned number needs 
> and delivering the TZ database to developers, they is not set up, nor do 
> they have *any* experience, to handle the load that end clients could 
> place on them.  Moreover, they are in no position to support millions of 
> people if something goes wrong.  And make no mistake: something will go 
> wrong.  I would be okay with a limited tzdist service for those who are 
> going to be distributing the data themselves, but the order of receivers 
> should be on 100s not millions.

The whole basis of the tzdist setup was that it provides a distributed 
means of serving the data. At the top level there is a need for primary 
publishers and since IANA *IS* a primary source then that material does 
need to be published somehow. The ONE think that is important here is 
that any publisher should properly identify the range of data that it is 
providing in addition to being able to service the differences between 
the current version of a rule set and that the client is actively using 
and any later changes. TZDIST is not simply a means of serving a single 
view of the TZ data, it is intended to be able to also provide an 
indication that the rule set that was used initially to normalise data 
has now changed. Bypassing that mechanism by only providing a current 
monolithic dump of the data is not what was intended and is why it is 
based on individual timezone identifiers, and each can be developed 
separately as further historic material becomes available.

We need to at least start to build the seeds of publishers but 
personally I'm not sure IANA is the right starting point since TZ is 
already a truncated data publisher ...

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk