Subject: [Tzdist] Ticket #22

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Aug 2014 07:57:59 -0400

All,

I believe the issues raised in this ticket is a non-issue.  The dtstamp 
in a list/expand response is tied to the particular server that issued 
the response.  If a client is pulling data from more than one server, it 
will have to keep track of multiple dtstamps and MUST NOT assume that 
using a dtstamp from server A in a request to server B will yield the 
expected results.  This seems clear to me in the current text, but if 
others feel differently, perhaps some clarifying text can be proposed.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Lester Caine <[email-masked]>
Date: Wed, 27 Aug 2014 13:17:29 +0100

> others feel differently, perhaps some clarifying text can be proposed.

See my post on #23 ...
But this is another facet of the same problem. It may be that the
correct process if access to a particular server is lost that the user
has to obtain a clean set of data from a different server. This still
leaves the problem that the user now has no idea if the new set of data
has introduced changes that they need to handle ... perhaps short of
comparing every new download with their cached copy? If 'last_mod' is a
required VTIMEZONE field they can at least skip records, but if working
with large 'expand' results this could be a problem for a light user
process?

-- 
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: Ken Murchison <[email-masked]>
Date: Wed, 27 Aug 2014 08:33:05 -0400

On 08/27/2014 08:17 AM, Lester Caine wrote:
> comparing every new download with their cached copy?

If they switch servers, they really have no choice because the dtstamp 
will most likely be different as will the ETags on the individual 
timezone resources.  I don't see a way around this, especially with 
iCalendar resources.  Perhaps if a JSON schema for the raw tzdata was 
used, this problem could be mitigated, but even then is the order of 
JSON objects mandatory (I'm not a JSON expert)?

> If 'last_mod' is a

Are you suggesting that the VTIMEZONE data contain a property that 
specifies the date-time of the underlying source data that the iCalendar 
data was derived from?

---

From: Lester Caine <[email-masked]>
Date: Wed, 27 Aug 2014 14:01:31 +0100

> JSON objects mandatory (I'm not a JSON expert)?

If a primary server fails how does the secondary level recover?

> specifies the date-time of the underlying source data that the iCalendar

If I am reading RFC5545 correctly, the optional LAST-MODIFIED field
contains a record of when that data was last updated. A few days ago I
would have EXPECTED that to be related to the source material, but it
seems that this is not normal practice in iCalendar systems and so is
perhaps just a timestamp on when the local copy was last downloaded? It
is not clear from the RFC?

Since the tzdist process is currently being defined, using this field as
a version stamp for the original published data makes more sense to me
than some random time which relates to when it was last cached? This can
then be used to flag when an updated version IS being supplied. Since
tzdist is the source of this data we do have control over what is
published and that is within scope?

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Aug 2014 09:57:26 -0400

Hi Lester,

> is not clear from the RFC?

For the primary server it could also be the last time when it applied a 
change to the iCalendar data - that may happen some time after the TZDB 
update - so there is no guarantee that two primary servers will have the 
same LAST-MODIFIED for the exact same TZDB data.

> published and that is within scope?

I would rather not put a version stamp in the iCalendar data because then 
every iCalendar VTIMEZONE object would be different for each release of the 
TZDB, potentially forcing clients to re-cache every timezone even though 
there has been no "substantive" change. A better place for the version info 
might be the capabilities - indeed that was one of the purposes of the 
"primary-source" object in capabilities.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Wed, 27 Aug 2014 10:06:11 -0400

The protocol provides enough information to allow clients to ensure they 
have an accurate copy of what a given server provides.

If a client switches servers it should flush it's data and reload.

You're correct in that the client has no idea whether or not any change 
to the data requires further action on the part of that client.

That's not a protocol issue - it's a data issue. Currently what we have 
to do is
a. Ensure we store enough information to make a good comparison (local 
time, UTC and the tzid).
b. Recalculate all affected dates and see if anything changed.

It's imperfect but its the best we can do with the current data. There 
are many things I'd like to see in the data but they don't affect the 
protocol.

We can be more specific about the vtimezone last-modified property but I 
think it's fine as it stands. I'm all for extra metadata but I think 
that discussion belongs on the tz list.

---

From: Lester Caine <[email-masked]>
Date: Wed, 27 Aug 2014 15:34:21 +0100

On 27/08/14 14:57, Cyrus Daboo wrote:
> Hi Lester,
> 
> --On August 27, 2014 at 2:01:31 PM +0100 Lester Caine
> <[email-masked]> wrote:
> 

In my book this is just a matter of defining HOW the protocol works.
There is nothing fundamentally stopping our requiring that LAST-MODIFIED
is a valid handle to ensure transfer integrity and allow clients with
intermittent connections to recover without having to do a complete new
download. That IS something a protocol should be providing?

> I would rather not put a version stamp in the iCalendar data because
> then every iCalendar VTIMEZONE object would be different for each
> release of the TZDB, potentially forcing clients to re-cache every
> timezone even though there has been no "substantive" change. A better
> place for the version info might be the capabilities - indeed that was
> one of the purposes of the "primary-source" object in capabilities.

The problem with that is that there is no way of ensuring what is read
in the capabilities replies matches what is in the cached data? I'm
looking at this from the other end. If I read "primary-source" and it
tells me I'm out of date, with your process I HAVE to download the whole
data set again? Even if there was only a change to a single tzid. If I
use the list/changedsince it should identify a subset of tzid's to
update but that only works if the process used to provide updates
ensures the correct data set is available before publishing that. A
timestamp of some sort is essential on each packet of data which is then
consistent down the supply chain. After several updates there WILL be an
assortment of LAST-MODIFIED tags that is to be expected simply because
only SOME VTIMEZONE have been modified? Or is your vie of how this works
that it will always download a complete new set of data when the
publisher provides an update?

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Aug 2014 10:52:44 -0400

Hi Lester,

> download. That IS something a protocol should be providing?

I don't see why or how an intermittent connection will cause a problem if a 
client is properly coded up. Let me describe an example client sync:

1) Client does action=list without a changedsince (initial sync)
2) Client caches the list response
3) For each time zone the client needs locally, it does an action=get and 
records the ETag value for each HTTP resource that is successfully 
downloaded
4) At regular intervals the client polls using action=list and changedsince 
set to the last valid list response dtstamp. That will return the set of 
time zones that have changed. That partial list can be applied to the 
existing cached list response to update the main list, but the partial list 
should also be saved to track the subsequent time zone sync operation to 
make sure all tzs of interest are sync'd.
5) For each changed timezone, the client does an action=get and uses an 
If-None-Match header in the request with the previous ETag for that 
resource. Data is only returned if it is really different from what came 
before. Once a successful update is done, that tz is removed from the 
pending up date list.

The key here is that the pending update list needs to be "transactional" 
such that intermitten connectivity does not cause updates to be lost.

Also, as you have pointed out there is a race condition between issuing an 
action=list and doing actual action=get that could mean the list dtstamp 
has changed prior to the get. That is not a big deal because the client 
will cache the ETag for the actual tz resource. So on the next action=list, 
where that tz gets reported as changed (in effect a false positive), the 
client will issue another action=get, but the If-None-Match condition 
results in no data being returned - which tells the client it already has 
the current tz.

Now, I do think the current draft is lacking in discussion of the 
ETag-condition action=get behavior, and I propose adding text to Section 
6.3 to cover that. I would also be willing to add a (non-mormative) 
appendix describing an example client sync procedure such as the one I 
outlined above, but I really want it to be in the most general of terms 
because client implementors really need to think carefully about that 
themselves.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Wed, 27 Aug 2014 17:41:57 +0100

On 27/08/14 15:52, Cyrus Daboo wrote:

OK this is filling in my mistakes ... I'd not considered relying only on
the ETag caching given the qualification on it's use in the get
definition? Re-reading it of cause , there SHOULD only be one timezone
specified so under what condition would it not?

> I don't see why or how an intermittent connection will cause a problem
> if a client is properly coded up. Let me describe an example client sync:
> 
> 3) For each time zone the client needs locally, it does an action=get
> and records the ETag value for each HTTP resource that is successfully
> downloaded
> 4) At regular intervals the client polls using action=list and
> changedsince set to the last valid list response dtstamp. That will
> return the set of time zones that have changed. That partial list can be
> applied to the existing cached list response to update the main list,
> but the partial list should also be saved to track the subsequent time
> zone sync operation to make sure all tzs of interest are sync'd.

> such that intermitten connectivity does not cause updates to be lost.

I'm more used to data replication which is transactional. I'm normally
doing all of this in databases. It's just different mindsets. I would
just be replicating the change rather than resending the whole data
package. But we are not reliant on a single data source which is what
ETag is enforcing? Having said that, since the data IS well defined why
would the generated ETag values be different between servers?

> Also, as you have pointed out there is a race condition between issuing
> an action=list and doing actual action=get that could mean the list
> dtstamp has changed prior to the get. That is not a big deal because the
> client will cache the ETag for the actual tz resource. So on the next
> action=list, where that tz gets reported as changed (in effect a false
> positive), the client will issue another action=get, but the
> If-None-Match condition results in no data being returned - which tells
> the client it already has the current tz.

The race condition I'm more concerned about here is that of a secondary
server, but rethinking things, it's more a case here of what is used to
feed that servers clients? While the server is downloading and
processing each new get, what is it's response to it's clients? Is each
new change used as it's downloaded, and IT'S list package changed each
time, or as I proposed previously does the whole update get processed
and then made active .. as I would expect the distributor to be doing.

I can see now why you may have such a diverse spread of versions while
I'm looking to maintain data that is NOT necessarily being used on the
same machine that the normalizing has been processed on so I NEED a
stable version identity for other machines to work with! I need
something that can be stored with the archived data and verified later,
which is what a properly managed last-modified provides.

> because client implementors really need to think carefully about that

This is not exactly obvious to a new reader :(
My own experience of caching can be somewhat hit and miss as the routing
and data proxies change. We have to design the mobile applications
around here so they work reliably off-net until a mobile connection can
be restored, and I'm not yet convinced that ETag can work in that
situation? A local database/webserver maintains operation until it can
replicate that back to the main service.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Aug 2014 10:16:45 -0400

Hi Lester,

> specified so under what condition would it not?

I think that text is left over from a time when we allowed multiple time 
zones to be returned in a single GET, but we later decided that was 
overkill and broke HTTP caching to an extent we were uncomfortable with. I 
will fix that text.

> would the generated ETag values be different between servers?

ETags are opaque tokens generated by the HTTP server. There is no 
requirement that different servers use the same method to generate those - 
some may choose an md5 hash, others sha1, and others something completely 
different. So ETags are not meant to represent state across servers - they 
only represent the state of the one resource they are "attached" to.

> which is what a properly managed last-modified provides.

By choosing to allow individual time zones to be downloaded, as opposed to 
the entire database all in one go, we do introduce the possibility of race 
conditions. In the case of a secondary server replicating what is on a 
primary, the secondary can achieve some level of integrity by using 
action=list&changedsince,action=get operations up to a point where the 
list+changedsince returns no results.

As far as clients go, they too are subject to this race - they too could 
repeat a list+changedsince immediately after doing a list/get sync to 
verify they have the latest.

> replicate that back to the main service.

ETag together with list+changedsince is the equivalent of what we do in 
CalDAV - there clients also use ETag together with the webdav sync REPORT 
to cache data from the server. Those client are all capable of working in 
an offline mode - and in fact a more complex mode in that changes made on 
the client whilst disconnected need to be sync'd up to the server when they 
re-connect, i.e., a two-way sync is involved. So I am confident what we 
have now is sufficient for a one-way sync from primary to secondary or 
server to client, though I am not confident I have convinced you of that 
fact yet :-)

-- 
Cyrus Daboo

---

From: Daniel Migault <[email-masked]>
Date: Thu, 28 Aug 2014 21:59:06 +0200

Do we have consensus that using Etag and "changedsince" for tz data
synchronization is sufficient for the use cases we are considering?

My understanding is is that it may not address all use cases, but most of
them. An appropriate synchronization would involve modifying the data
format which is another topic.

I believe we will need to make similar trade-off considering POSH/TLS.

BR,
Daniel

On Thu, Aug 28, 2014 at 4:16 PM, Cyrus Daboo <[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: Ken Murchison <[email-masked]>
Date: Thu, 28 Aug 2014 16:02:13 -0400

I agree that ETag + "changedsince" is sufficient.

On 08/28/2014 03:59 PM, Daniel Migault wrote:
> My understanding is is that it may not address all use cases, but most 
> of them. An appropriate synchronization would involve modifying the 
> data format which is another topic.
>
> On Thu, Aug 28, 2014 at 4:16 PM, Cyrus Daboo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Lester,
>
>
>     --On August 27, 2014 at 5:41:57 PM +0100 Lester Caine
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I think that text is left over from a time when we allowed
>     multiple time zones to be returned in a single GET, but we later
>     decided that was overkill and broke HTTP caching to an extent we
>     were uncomfortable with. I will fix that text.
>
>
>     requirement that different servers use the same method to generate
>     those - some may choose an md5 hash, others sha1, and others
>     something completely different. So ETags are not meant to
>     represent state across servers - they only represent the state of
>     the one resource they are "attached" to.
>
>
>     By choosing to allow individual time zones to be downloaded, as
>     opposed to the entire database all in one go, we do introduce the
>     possibility of race conditions. In the case of a secondary server
>     replicating what is on a primary, the secondary can achieve some
>     level of integrity by using action=list&changedsince,action=get
>     operations up to a point where the list+changedsince returns no
>     results.
>
>     As far as clients go, they too are subject to this race - they too
>     could repeat a list+changedsince immediately after doing a
>     list/get sync to verify they have the latest.
>
>
>     ETag together with list+changedsince is the equivalent of what we
>     do in CalDAV - there clients also use ETag together with the
>     webdav sync REPORT to cache data from the server. Those client are
>     all capable of working in an offline mode - and in fact a more
>     complex mode in that changes made on the client whilst
>     disconnected need to be sync'd up to the server when they
>     re-connect, i.e., a two-way sync is involved. So I am confident
>     what we have now is sufficient for a one-way sync from primary to
>     secondary or server to client, though I am not confident I have
>     convinced you of that fact yet :-)
>
>     -- 
>     Cyrus Daboo
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Eggert <[email-masked]>
Date: Thu, 28 Aug 2014 13:45:11 -0700

Daniel Migault wrote:
> them.

I'm afraid that Etag+changedsince doesn't suffice to handle reasonably 
common use cases.  As discussed in Ticket #18 
<http://trac.tools.ietf.org/wg/tzdist/trac/ticket/18>, Etag together 
with list+changedsince would have mishandled the transition from 2014e 
to 2014f, since it would have missed the replacement of some zones by 
aliases.  The upcoming 2014g release would similarly be mishandled.  So 
that's two consecutive tz releases where Etag+changedsince wouldn't suffice.

> An appropriate synchronization would involve modifying the data

I guess I'm not seeing why this problem must be addressed by modifying 
the VTIMEZONE data format.  Even if we wanted to put dbversion info into 
the VTIMEZONE data, we could do that by convention, putting it into the 
TZURL for example; this wouldn't require changing the VTIMEZONE format. 
  And we needn't put the dbversion info into the VTIMEZONE data; we 
could put it into the metadata.

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Aug 2014 17:06:00 -0400

Hi Paul,

--On August 28, 2014 at 1:45:11 PM -0700 Paul Eggert <[email-masked]> 
wrote:

> <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/18>, Etag together with
> list+changedsince would have mishandled the transition from 2014e to
> 2014f, since it would have missed the replacement of some zones by

What wouldn't have worked in this case:

1) Clients syncs the list for 2014e
2) Clients uses list+changedsince after the server has updated to 2014f
3) Server returns Asia/Harbin as changed and also Asia/Shanghai, which now 
lists Asia/Harbin as an alias.

At that point, the client can throw away its cached (old) Asia/Harbin data, 
then simply link the Asia/Shanghai data in its place. Of course it does 
require the server to report both those changes simultaneously in the list 
response but does imply the need for the list response to be atomic wrt 
changes the publisher makes.

-- 
Cyrus Daboo

---

From: Paul Eggert <[email-masked]>
Date: Thu, 28 Aug 2014 14:42:48 -0700

Cyrus Daboo wrote:
> 3) Server returns Asia/Harbin as changed and also Asia/Shanghai, which
> now lists Asia/Harbin as an alias.
>

That approach would seem to rely on two assumptions that aren't in the spec.

1. Creating an alias from Asia/Harbin to Asia/Shanghai must be 
considered to be a substantive change to Asia/Shanghai.

2. When the database is changed, a zone must be replaced by an alias, 
and not simply removed.

Assumption (1) isn't required by Section 4.1.3, unfortunately.

Assumption (2) is not true for distributions that omit the data in 
'backward' file, as these distributions will indeed remove zones without 
creating links when switching from 2014e to 2014f.  I think FreeBSD 
falls into this category, so Assumption (2) would fail on FreeBSD-like 
servers.

---

From: Lester Caine <[email-masked]>
Date: Fri, 29 Aug 2014 00:38:43 +0100

On 28/08/14 15:16, Cyrus Daboo wrote:
> CalDAV - there clients also use ETag together with the webdav sync
> REPORT to cache data from the server. Those client are all capable of
> working in an offline mode - and in fact a more complex mode in that
> changes made on the client whilst disconnected need to be sync'd up to
> the server when they re-connect, i.e., a two-way sync is involved. So I
> am confident what we have now is sufficient for a one-way sync from
> primary to secondary or server to client, though I am not confident I
> have convinced you of that fact yet :-)

Since by your definition, ETag is specifically not defined I simply
can't see how clients who are using different servers in diverse
locations as their source can be guaranteed to be looking at the same
data? You have already agreed that updates do need to be atomic, which
does address a part of the problem. The part I am still unable to work
through is where the client has a later version of the data to that
which the source document was published using? I think your method of
working is reliant on everybody actually having the latest version
'atomically' which is simply not practical?

And my remaining hole is STILL that of already published data using a
version of the timezone data which has yet to be updated but for which
the original tzdist server is no longer on line, so list+changedsince
will not work because the ETag information from that server has been
lost. Simply downloading a new set from a new server fails because the
material was not created with that 'version' of timezone data.

In an environment where all of the events in a multitude of calendars
are always updated to the same version of timezone data your system of
working may be able to work since all of the 'race tracks' will be
flattened out eventually, but if people are working off-net they WILL be
working with older versions of either timezone data or source event
data. The source event data is created using a particular version of
tzdist distribution data and the client then needs to know what version
that is in order to use changedsince at all. But we do not have a stable
defined field we can use to provide that version detail? dtstamp
provided by the source's tzdist server is not defined to be the same as
the current client tzdist server? Which is why a client may well be
looking at a different view of the schedule to the publisher and have no
idea there is a problem :(

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Aug 2014 20:39:25 -0400

Hi Paul,

> That approach would seem to rely on two assumptions that aren't in the

Yes and they should be to better deal with this problem.

> 1. Creating an alias from Asia/Harbin to Asia/Shanghai must be considered
> to be a substantive change to Asia/Shanghai.

Agreed. In the "substantive" debate I am leaning towards removing that 
entirely and saying any change to the data or meta-data should trigger a 
dtstamp change.

> 2. When the database is changed, a zone must be replaced by an alias, and
> not simply removed.

So we need some type of new response indicator in the list response to 
cover the case of complete removal, and replacement by alias. We can 
probably handle that by adding a "status" object to the "timezone" object 
in the list response. Then we can define codes for specific status. i.e., 
we can define the equivalent of HTTP's 404 - to indicate removal - and 302 
- redirect/replacement via an alias.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Aug 2014 21:32:44 -0400

Hi Lester,

> idea there is a problem :(

Right - and that happens today. My goal is to improve that situation as 
much as possible, without overly burdening the service with strict 
requirements of 100% match across 100% of the clients 100% of the time. The 
only way to have the 100% guarantee is to send the actual time zone data 
along with the event - which is exactly what iCalendar does today. But that 
is also exactly what we want to get away from!

So the question is can we build a system that provides a reasonable 
guarantee that clients are kept up to date with reliable data. I think the 
current protocol does do a reasonable job of providing a way for timely 
updates to happen. For that I think we can live with a few days latency in 
updates that may occur because the different servers clients are using 
update at different rates. So long as the data eventually gets updated 
within a reasonable amount of time we should be OK. Of course there is 
little we can do if a government decides to make a change with only a few 
days notice - that is always going to be disruptive.

>From the data reliability standpoint, if we adopt the "time zones by 
reference" approach where only the time zone id is included in the event 
data, then of course there needs to be agreement on the tzids - two 
publishers using America/New_York but with different definitions is a 
problem. To solve that iCalendar does support a "namespace" prefix for the 
TZID, e.g., /Olson/America/New_York vs /Cyrus/America/New_York. Using such 
a prefix would be the best way to deal with that, but would cause immediate 
interoperability problems with existing clients that use the Olson and 
Microsoft tzids without any prefix. What might be feasible for this case is 
to define a new iCalendar property for include in place of the VTIMEZONE 
object. The new property, say TZDIST-SOURCE, would indicate the source of 
the time zone data used by the author of the event. Clients that care, can 
then verify that the definition they have from their own source matches the 
one from the author's source.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Fri, 29 Aug 2014 08:57:54 +0100

On 29/08/14 02:32, Cyrus Daboo wrote:
> guarantee that clients are kept up to date with reliable data. I think
> the current protocol does do a reasonable job of providing a way for
> timely updates to happen. For that I think we can live with a few days
> latency in updates that may occur because the different servers clients
> are using update at different rates. So long as the data eventually gets
> updated within a reasonable amount of time we should be OK. Of course
> there is little we can do if a government decides to make a change with
> only a few days notice - that is always going to be disruptive.

Ignoring the charter just for a moment. On my todo list is providing a
fix to this problem. As I have said in another post, nothing like
'automatically fixing' but simply a hand up saying 'Here is the
schedule, but note that the local times at xxx may change before the
meeting. Data provenance IS important. That users from other sides of
the world will NOT know that is the hole I'd ideally like to fix.