Re: [ietf-privacy] [Tzdist] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05

[Lester Caine <[e-mail]>]

On 01/02/15 21:29, Paul Eggert wrote:
>> it does make sense to provide a
>> "full set of tz data" option in the protocol to allow clients to get
>> the entire
>> set of current data without exposing which specific time zone(s) they are
>> actually interested in (which would also remove the need for them to
>> use etags).
> 
> Yes.  Although clients could omit etags, my guess is that it'd be OK in
> most cases privacy-wise to use them, so long as the etags are global
> (one per tz database version, e.g., "tz2015a") rather than
> per-server-and-database-version (e.g.,
> "tz2015a-04F56E6866304E628CA1C45B").  That way, etags should provide
> little tracking info.  A bonus is that a client could switch servers
> without having to re-get the tz database from the new server.

A debate on how an etag is generated on another list implies that is
should include a hash of the data, but I am sure that the spec does not
require that and allows a fully defined etag? The strong/weak element
could come into play where the 'style' of data is an addition, but every
reply with a  'tz2015a' head would contain the same core data (ignoring
backzone problem). I'm not sure if that is necessary if the request
identifies the correct style required, but either way the tag itself is
generic world wide and can be accepted when a different server has to be
accessed for any reason.

In the context of the 'changedsince', asking for 'latest' where one is
currently using 'tz2014j' will return a new packet with 'tz2015a' while
asking for 'changedsince=tz2014j' will return just the differences. If
'latest' returns a complete data dump then the local machine has to work
out if there are any changes which require further work, while the
difference set if sent as a simple list of TZid's allows the client to
ignore any update they are not using id's from. It is up to them if they
download a 'full dump', just the TZid's that have changed, or only the
one's they are using.

For embedded devices asking for a simple 'expand' etag will give them a
'same' message until the version changes. If there is a version change,
but it does not affect the content of this particular packet then one
could say that they don't need to do anything, but given that this is
such a rare occurrence, simply downloading again is fine. If the client
does need to know if the next transition has changed then that is best
handled locally. For this action I don't see that downloading a complete
data set is necessary at all? Since the cache mechanism will time out at
regular intervals, even the etag mechanism will give a reply when
nothing has changed?

-- 
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