Subject: [Tzdist] Issue #8 TLS and POSH

From: Daniel Migault <[email-masked]>
Date: Sun, 31 Aug 2014 16:52:48 +0200

Hi,

Does tzdist suffers from POSH ?
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/8

To me the question is do we expect tzdist traffic to be address by a small
group of servers, or do we expect that the amount of exchanged data will
need to have the tzdist servers hosted by third party like cloud/web
providers.

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Sun, 31 Aug 2014 16:18:26 +0100

On 31/08/14 15:52, Daniel Migault wrote:
> 
> To me the question is do we expect tzdist traffic to be address by a
> small group of servers, or do we expect that the amount of exchanged
> data will need to have the tzdist servers hosted by third party like
> cloud/web providers.

Given that the current method of distribution is via the OS updates, it
is perhaps a little surprising that people ARE talking about a full
distribution system. Another suggestion is that since the data set is
'quite small' why not just distribute the whole package when there is an
update. Both seem a little strange when the majority of data updates are
exceedingly small, and if the distribution mechanism already has the
bulk of the data cached locally, potentially many race problems could be
avoided simply by supplying a single self contained update packet.
Everything else is distributed by a diff patch process.

For devices that have no need or a full calendar system, simply reading
the results of a lookup as 'POSH' is probably all that is needed. They
only need a very small subset of data, and a simple get may be all that
is needed.

That we have the draft we do now is more to do with how the charter has
been defined rather than the best way of actually achieving what is
needed? Add a proper DST id to the browser message so that the correct
data can be accessed would plug an number of holes and further simplify
the 'light' distribution requirements. While the heavy weight system IS
only a caching mechanism, so why transmit any more than necessary to
update it?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 31 Aug 2014 12:13:24 -0400

Hi Lester,

--On August 31, 2014 at 4:18:26 PM +0100 Lester Caine <[email-masked]> 
wrote:

> distribution system.

Actually let's look at that: in fact on my system right now I have zoneinfo 
files for the OS, Python (two: one in pytz package, the other in dateutil), 
Java and postgres. Multiple update processes are involved for each of 
those. It would be nice to have one single tz data repository for the 
entire OS with a set of apis that any package could rely on. In the absence 
of that, at least having all those separate zoneinfo's kept up to date (in 
step with each other) would be better than the current state of affairs.

> Another suggestion is that since the data set is

"Quite small" when scaled to potentially 100's of millions of devices 
quickly becomes "quite large" - well actually humungous! Allowing clients 
to get only what they care about and only what has changed with save 
bandwidth and cpu (and ultimately other resources like power).

> only a caching mechanism, so why transmit any more than necessary to

I guess I don't understand what the current protocol does not do here. It 
supports clients just getting what they are about, or doing quick updates 
for changes, as well as listing and downloading the entire set of data.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Sun, 31 Aug 2014 21:49:36 +0100

On 31/08/14 17:13, Cyrus Daboo wrote:
> quickly becomes "quite large" - well actually humungous! Allowing
> clients to get only what they care about and only what has changed with
> save bandwidth and cpu (and ultimately other resources like power).

Now that was exactly how I was going to word it ...
Except my point was that rather than getting a new copy just of the bit
they want they work with a cached copy and only need to get an update IF
that changes ...