Subject: [Tzdist] Layers of capability ( off scope )

From: Lester Caine <[email-masked]>
Date: Mon, 01 Sep 2014 10:53:51 +0100

On 31/08/14 17:13, Cyrus Daboo wrote:
>> 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.
> 
> 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.

To be honest when I first saw the charter for tzdist I thought - what is
the point ...

If there is no standardisation on data then many of these 'consumers'
are going to do their own thing anyway which in an open world they are
entitled to. Even when the world agrees on standards other bodies 'buy'
their own get out of jail card to bypass them :(

tzdist is not going to do what you or I want Cyrus ... what we need
before that is to agree on just what data is valid and make that the
standard base. THEN truncating to time periods or limited views like
'ascii expand' can be made to work reliably and everybody gets the same
answer.

I can see a path through which fits Tobias's model, does not go out of
scope and will fold back to a minimum requirement. That we can create a
publisher which has substantial content is out of scope, but there is a
minimum set of material that is required to provided a fully defined
timezone. from which an 'expand' view can be built? That WILL at this
stage be a truncated view and I don't think we should try to produce an
un-truncated view initially. Once we have that wrapper, then we can
agree on the sub-set of data that will service it, and the zone1970
subset fits that bill? Any changes to that subset will result in an
update needing to be processed. That may be a short notice change to a
single or small group of tzid's or a more general update due to more
scheduled reorganisation. Anything affecting current and near future
events, so just as there is a truncated start date - there is also a
truncated end date beyond which 'expand' will not go.

On the back burner is better support for historic material, which is
partly down to improving the provenance of data on tz. While publishers
can pick and choose what they include or not should NOT be published as
un-truncated data! If that means initially a 1970 cut-off then we have
to accept that. rolling back earlier than that is a discussion for tz
which is still currently ongoing. For tzdist, perhaps we need a tzid
based truncation mechanism so that some tzid's can start earlier ... or
end later. Which is then a stepping stone to a fully configured system?

I hope others will help with their own research like
http://timedb.co.uk/wiki/view/Europe/Isle_of_Man

-- 
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: Mon, 01 Sep 2014 15:14:30 -0400

Hi Lester,

--On August 31, 2014 at 9:49:36 PM +0100 Lester Caine <[email-masked]> 
wrote:

>> "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).
>
> 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 ...

So you are suggesting extending the API to allow a client to indicate a 
range of times it is interested in getting tz data for, and the server only 
returns updates if the tz observances for that range are different from 
what the client previously sync'd?

My main concern with that is the additional overhead required by a server 
to support tracking time zone changes over time. Right now a tzdist server 
is easy to implement because you only need a "snapshot" of the current set 
of tz data - past versions are not needed. All the server needs to do is 
maintain the action=list meta-data for the dtstamps. With that it can 
satisfy any of the requests types we have. If instead, the server has to 
calculate a diff from some arbitrary point in the past (when the client 
last sync'd) then it needs to maintain much more data associated with that.

So the question is, is this "diff" approach essential to getting tzdist 
adopted now, or can we treat sending diffs to clients as an optimization 
that can easily be handled as an extension once we have established tzdist 
as a useful protocol? History is littered with examples of protocols that 
had everything thrown into them at the start and as a result the barrier to 
entry was huge. Whereas, many successful protocols started out with a 
smaller scope but with good, built-in extensibility to keep them viable in 
the long term. I am a proponent of the later model.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Mon, 01 Sep 2014 21:17:41 +0100

On 01/09/14 20:14, Cyrus Daboo wrote:
> that can easily be handled as an extension once we have established
> tzdist as a useful protocol? History is littered with examples of
> protocols that had everything thrown into them at the start and as a
> result the barrier to entry was huge. Whereas, many successful protocols
> started out with a smaller scope but with good, built-in extensibility
> to keep them viable in the long term. I am a proponent of the later model.

Cyrus - I think THIS thread needs wiping as we are on different tacks!

I was intending to point out that a the suggestion that a simple
solution to updates was just to send the whole data set again was
somewhat naive. Please see my other post about simplifying the target
for the first pass of an impolementation.

Simple clock devices need nothing more than a small update if a
transition they are using changes. In practice that same small update is
ALL that is needed by everybody, but I'm not sure at this stage we can
implement that. We are on the same path, running parallel ...

---

From: Paul Eggert <[email-masked]>
Date: Mon, 01 Sep 2014 13:28:07 -0700

Cyrus Daboo wrote:
> is this "diff" approach essential to getting tzdist adopted now, or can
> we treat sending diffs to clients as an optimization that can easily be
> handled as an extension

It's not essential.  My guess, without having measured this of course, 
is that the benefit of any diff-based protocol would exceed its cost, 
even ignoring the cost of developing the extra client and server software.

For example, suppose a client is interested in X, where X stands for 
America/Los_Angeles time from 2013 through 2016.  The answer to any 
query about X has been the same since tz release 2005l, so adding a diff 
protocol would help only the extremely unlikely client that is at least 
nine years old and that has never updated.

True, zones like Africa/Cairo mutate more often.  However, even for 
these zones a diff-based protocol wouldn't help much, as the size of the 
diff for 2013 through 2016 wouldn't be that much smaller than all the 
data for 2013 through 2016, once one takes network overhead into account.

---

From: Lester Caine <[email-masked]>
Date: Mon, 01 Sep 2014 21:44:42 +0100

> data for 2013 through 2016, once one takes network overhead into account.

Having truncated the data, the data packet is 'contained' already.
However a few tzid's are quite large when taking the full history, and
it's more likely that 'just' the next transition needs a tweak rather
than the whole history? So an additional function later that may be
useful is 'update' to just supply a 'diff' set to help reduce traffic.
That function would give an atomic update of all the data of a data version.

Since 'zip' may already be in use with the html link, all of this may
well be academic anyway?

---

From: Paul Eggert <[email-masked]>
Date: Mon, 01 Sep 2014 14:53:32 -0700

Lester Caine wrote:
> than the whole history?

Yes, but even taking that into account I'm skeptical that a diff-based 
protocol would be a big-enough win, if we count all the overhead of 
supporting such a protocol.  A diff-based protocol would impose extra 
costs not just on the server (some of which Cyrus Daboo mentioned) but 
also on the client side.  Some of these costs will involve worrying 
about attacks, as it tends to be easier for an attacker to exploit a 
diff- or dictionary-based protocol.

This is an area where intuition can take us only so far.  Measurements 
of the more-complicated approach would help to make the case that it's 
worth the cost.  Such measurements should take compression (which you 
mentioned) and security into account.  Since we have no measurements, we 
can only guess which approach would be better; and the default ought to 
be to keep things simple.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Sep 2014 10:53:25 +0200

> Since 'zip' may already be in use with the html link, all of this may

Well this is precisely what I was saying to Tobias.  There is such a
thing as optimization.  So long as we are in the right ballpark, I don't
see why this has to be an exact fit.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Sep 2014 10:55:29 +0200

> see why this has to be an exact fit.

And that should have read "over-optimization".

Eliot

---

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Sep 2014 11:35:41 +0200

Hi,

Currently this thread has discussed whether additional option should be
added in order to reduce the amount of data to be send. I believe we agree
in saying these optimization are not obvious, and should not be considered
in the current draft. They may however be developed as extension if there
is a need for them.

That said, the original question mostly concerned the server side and the
POSH issue.

My understanding is current specs do not make TLS explicit to protect the
exchange, and that amount of  traffic  seems reasonable and the current
spec may not consider tzdist servers hosted by third party web host. [See
also ticket #3]

As a result I would rather consider tzdist protocol does not suffer from
POSH.

Please let me know if you agree or disagree, so I can close (or not) ticket
#8.

BR
Regards,
Daniel

On Tue, Sep 2, 2014 at 10:55 AM, Eliot Lear <[email-masked]> wrote:

> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>
>

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

---

From: Lester Caine <[email-masked]>
Date: Tue, 02 Sep 2014 10:50:02 +0100

On 02/09/14 10:35, Daniel Migault wrote:
> Please let me know if you agree or disagree, so I can close (or not)
> ticket #8.

I must say that I could not see why the statement was even made?
Simple devices will use simple html processes to get what they need so I
expect what I am seeing.
But I may be missing something? I'm not seeing any argument that there
is a problem.

---

From: Lester Caine <[email-masked]>
Date: Tue, 02 Sep 2014 23:09:12 +0100

> But I may be missing something? I'm not seeing any argument that there

I've been reviewing my understanding of POSH for which I have
http://microformats.org/wiki/posh as my crib sheet, but I still don't
understand why this ticket exists. The discussion on formats for times
seems more POSH related than the current draft format?

---

From: Paul Eggert <[email-masked]>
Date: Tue, 02 Sep 2014 15:22:04 -0700

Lester Caine wrote:
> understand why this ticket exists.

Admittedly the ticket is too cryptic.  In the tzdist context I think 
POSH stands for PKIX Over Secure HTTP, not for Plain Old Semantic HTML. 
  Please see:

https://tools.ietf.org/html/draft-ietf-xmpp-posh-01

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 00:00:14 +0100

> https://tools.ietf.org/html/draft-ietf-xmpp-posh-01

OK that makes more sense ... I'm glad I'm normally running on internal
networks ...

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Sep 2014 06:23:14 +0200

On 9/3/14, 1:00 AM, Lester Caine wrote:
>> POSH stands for PKIX Over Secure HTTP, not for Plain Old Semantic
>> HTML. Please see: https://tools.ietf.org/html/draft-ietf-xmpp-posh-01 

Fair point.  To be clearer, there is a problem if there are going to be
many tenants of a service who do themselves do not wish to provide
private key information to the service.  Having thought about this some,
it probably is NOT a tzdist problem, and this ticket shoulld probably be
closed if others agree.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 08:57:46 +0100

> it probably is NOT a tzdist problem, and this ticket shoulld probably be

That some systems will want to use this without the encumbrance of
'secure link' mechanisms is a given in my book. I'm probably still on
SSH where I use them ... and if we could be a little less cryptic in the
discussions :)