Subject: [Tzdist] Time Zone Distribution Protocol

From: Bradley White <[email-masked]>
Date: Thu, 14 Aug 2014 17:45:41 -0400

On Fri, Jul 18, 2014 at 8:21 AM, The IESG <[email-masked]> wrote:

> This working group will:
>
> - Define a time zone data distribution protocol that allows for
> efficient, timely updates of time zone data to be delivered to clients.
> This protocol must scale to vast numbers of clients, such as the
> potential "internet of things" devices, as well as to today's desktop
> computers and servers.
>

On Thu, Aug 14, 2014 at 5:12 AM, Daniel Migault <[email-masked]> wrote:

> Comments should be emailed on the [email-masked] mailing list.
>

A long time ago there was a proposal on the "tz" mailing list to return
zoneinfo data in a DNS TXT record in response to a query for a domain name
like New_York.America.zoneinfo.tz.  As far as I know nothing ever came of
it.

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 15 Aug 2014 00:26:11 +0200

> like New_York.America.zoneinfo.tz.  As far as I know nothing ever came of

Is "_" allowed in domain names?

Also, there are other characters that might be problematic in some environments.

2012-05-24 I sent a proposal to remove "-" and "."
http://mm.icann.org/pipermail/tz/2012-May/017936.html
But there was no response on the list by Paul Eggert who is the only
person in control of everything in the IANA time zone database.

So, since
https://datatracker.ietf.org/doc/charter-ietf-tzdist/01/
says

"The following are Out of scope for the working group:"
...
"The naming process for time zone identifiers."

And that process can lead to any identifier the TZ Coordinator chooses
- he is not even bound by any policy, there is only a Theory file,
containing lot of stuff that is not enforced - one cannot use the
tzids the way you write.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Daniel Migault <[email-masked]>
Date: Sat, 16 Aug 2014 20:42:40 +0200

Thanks for raising this point about using DNS or HTTP.

Current drafts use HTTP. Personally, I do not think DNS would be
appropriate as the timezone exchange is not a simple UDP query - response.
First queries are not so simple and have multiple parameters, then
responses may be also large enough to use TCP even with DNS.

Please let's share your opinion on that topic.

BR,
Daniel

On Thu, Aug 14, 2014 at 11:45 PM, Bradley White <[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: Tobias Conradi <[email-masked]>
Date: Sat, 16 Aug 2014 20:50:04 +0200

On Sat, Aug 16, 2014 at 8:42 PM, Daniel Migault <[email-masked]> wrote:
> Current drafts
They are outdated.

> use HTTP. Personally, I do not think DNS would be appropriate
> as the timezone exchange is not a simple UDP query - response. First queries
> are not so simple and have multiple parameters, then responses may be also
> large enough to use TCP even with DNS.
>
Why are the drafts not updated to reflect current best knowledge about
what they shall be like?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Sat, 16 Aug 2014 21:39:49 +0100

> Why are the drafts not updated to reflect current best knowledge about

Because you update a draft when consensus has been reached about a change,
not just because one person (even the author) has made a suggestion.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: [email-masked]     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646

---

From: Tobias Conradi <[email-masked]>
Date: Sat, 16 Aug 2014 23:01:00 +0200

On Sat, Aug 16, 2014 at 10:39 PM, Clive D.W. Feather <[email-masked]> wrote:
> Because you
me? How can I?

> update a draft when consensus has been reached about a change,
I thought there was? Even enclosed in **...**

http://www.ietf.org/mail-archive/web/tzdist/current/msg00014.html

> not just because one person (even the author) has made a suggestion.
Not applicable here, see

http://www.ietf.org/mail-archive/web/tzdist/current/msg00014.html

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Sun, 17 Aug 2014 07:30:57 +0100

> http://www.ietf.org/mail-archive/web/tzdist/current/msg00014.html

And that is not an acceptable change to some of us so just be happy we
are letting you get away with it. All of my own work will continue to
use timezone since as far as I am concerned that is the correct spelling
for a WORD describing what is being developed.

We have a lot of historic material that contains the correct word, and
rewriting that is NOT acceptable. The drafts were created on lists where
timezone is the correct terminology, and for them to be rewritten now
the reason for the change needs to be documented so we can correctly
track the development of the documents. These are merely source
documents and now a version is needed related to the tzdist project.
That step has not yet been undertaken ...

I'm tied up at an exhibition until tomorrow, but have a set of points
developing which I'll post in a couple of days.

-- 
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: [email-masked]
Date: Sun, 17 Aug 2014 11:21:10 +0100 (BST)

Nowadays we seem to spend more time fighting the system and coping with
other peoples updates than getting any productive work done. I would much
rather get back to genealogical reasearch rather than trying to ensure
that the basis for the times I'm working with is right.

I am a long term user of normalised time data going back to a time when
trains did not run over night and everything reset at 2AM for the next
day. Switching systems to normalised time and displaying the correct time
was relatively easy where one only had to worry about DST on one time
zone, not add traffic across several timezones ( when someone built a
tunnel ;) ) and while the need for normalizing is even more obvious, the
provisioning is hamstrung by a few strange decisions. While propriatary
equipment can be managed to a resonable extent, the increasing need to
rely on browser access creates the first problem with it's reliance on a
simple time offset, and unreliable location information. While one can
service an anonymous user today, next week is a gamble. Ensuring that more
accurate tz offset information is not a lot of use without the backup to
use it universally?

Next problem, and why I have been endevouring to contribute to tz, is the
poor quality of historic tz data. Some may not be aware that there has
been an ongoing debate on tz if there is any point including data prior to
1970 when 'computer time' started, but there is a growing volume of
historic material which if normailized needs to be reliable. That a
'default' tz database extract is already truncated to 1970 means that the
historic data is not getting the attention that it deserves, and I hope
that the base for tzdist IS a FULL historic record even if that requires
an alternate source to provide it?

One of the arguments against the current historic data is the poor
provenance, although for some areas of the world that has been being
addressed as more people are taking an interest and providing local access
to material that would not otherwise be accessible. In some cases, third
world material is better supported these days than the major countries as
more and more archive material is scanned. This is uncovering evidence to
plug the holes that currently exist, as recently demonstrated by an update
to the Russian data. The problem this leads to and which is perhaps even
more relevent to short term tz changes is that a simple tz reference is
not adaquate when normalizing data. I was looking at simply recording the
tz version to go along with any normalized data, but on first reading of
the current drafts ( I need more time to digest a bit better ) it would
seem that we need to timestamp the action of normalizing, and then use
that second timestamp to ensure that when a normalized value is displayed
there has not been a change in the offset subsequently. I was originally
looking at this for updating historic material, but of cause DST data is
changing it seems almost daily, so a meeting aranged for next week may
already have an invalid offset?

What is long overdue is a stable base to work from, and it's only as
recently as the last week that the historic material has been better
supported in tz and updates going back a couple of years now included.
While tzdist does not take any responcibility for any of the source data,
non of this will work without a proper cooperation, and the distribution
mechanism SHOULD ensure that the reliability of any archived data can be
maintained going forward. To that end it would seem that the iCalendar
standard does not actually support the concept of normalizing data. While
it provides for a local time with a timezone, the UTC time does not make
provison to identify what timezone it created from, so if the timezone
offset changes at the location due perhaps to a short notice change in DST
then there is no way of flagging the change to other users of that data?
While the buck has been passed on what data is provided, surely the basic
mechanism needs to have the facility to identify changes to previous
'replies', especially with the single request service mechanism?

The current target seems only to support a limited range of functions and
while lip service is being paid to historic data, flagging a difference in
results needs to be addressed even if only for short term DST changes? If
you have advertised a meeting for next week and used a UTC time for other
sites then one needs to know there is a problem? Manually working through
the results of a change can be difficult if you do not know that the old
data has been used in the first place. Not a problem for txdist, but I
content that tzdist should at least provide the tools to manage it
automatically?

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Aug 2014 10:33:12 -0400

Hi [email-masked],

> content that tzdist should at least provide the tools to manage it

Yes that is an interesting point. In the past Mike and I (and others at 
CalConnect that worked on our draft) have discussed having an additional 
piece to the protocol that would allow the client to receive information 
about which range of dates/times are impacted by a change to a time zone 
definition. That would allow thin clients to avoid having to do such a diff 
client-side to figure out the impact of a time zone change. At the time we 
decided not to incorporate such a feature in the base protocol, but instead 
decided it would make a good extension to the protocol (we have tried to 
design our protocol with extensibility).

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Aug 2014 10:45:51 -0400

Hi Bradley,

> like New_York.America.zoneinfo.tz.  As far as I know nothing ever came of

As Daniel pointed out there are a bunch of reasons why DNS might not be 
appropriate - but it is definitely worth hearing from everyone else on that 
issue to make sure there is good consensus one way or the other.

Now, as for zoneinfo itself: one thing discussed by Mike and I (and others 
at CalConnect who helped with our draft), was the possibility of allowing 
actual zoneinfo files to be distributed via the tzdist protocol. We tried 
to build in extensibility that would allow that. The key thing we would 
need is a MIME content-type to be defined for the zoneinfo format - e.g. 
something like "application/timezone+zoneinfo". With that, a tzdist server 
could advertise that it can return data in that format (in addition to the 
iCalendar format we currently support).

If we did that, then operating systems that used the zoneinfo format could 
become tzdist clients, and update their data directly from a tzdist server 
rather than relying on regular operating system update processes to do so.

Any other timezone data format could be treated in a similar way (e.g., 
someone could come up with an interchange format for the Windows time zone 
data stored in the Windows registry and arrange for that to be distributed 
via tzdist).

I think all of that is out of scope for this WG right now, beyond making 
sure we have proper extensibility in the tzdist protocol itself.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Mon, 18 Aug 2014 16:55:15 +0200

On Mon, Aug 18, 2014 at 4:45 PM, Cyrus Daboo <[email-masked]> wrote:
> actual zoneinfo files to be distributed via the tzdist protocol.
These are governed by Paul Eggert. He can change the format at any
point he likes. Specifying in a RFC a format that itself is not
governed by any formal standard looks weird to me. But I am new to
IETF. Is there any current RFC that does this?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Aug 2014 16:59:29 +0200

<no hats>

> IETF. Is there any current RFC that does this?

Happens all the time.  In essence the IETF builds containers for lots of
content, and that is what MIME itself provides the means to move;
whether it is standardized or not.  It just has to be properly
identified.  That's what an IANA registration is for.

Eliot

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 29 Aug 2014 00:50:20 -0400

I think I commented on this once before, but I'll comment (as an interested
observer) with two thoughts:

1. I that if the data format for distributing timezone is standardized, the
files will be fairly small (probably larger than the Olsen text file but
still "small" in the sense of files pulled over IP)
2. My proposal was for DNS to return *all* the timezone file when receiving
some sort of specialized query (which I hadn't determined), rather than
trying to return data for just one timezone.  Timezone data needs to be
usable "offline" and pulling the entire file is, in my opinion, the best way
to have an offline copy.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: calsify [mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Monday, August 18, 2014 10:46 AM
To: Bradley White; [email-masked]; [email-masked]
Subject: Re: [calsify] [Tzdist] Time Zone Distribution Protocol

Hi Bradley,

-- 
Cyrus Daboo

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

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 29 Aug 2014 15:59:21 +0200

> usable "offline" and pulling the entire file is, in my opinion, the best way

I absolutely agree. +1

> Interested Bystander, Non-Inc.

Martin Burnicki

Another interested listener. ;-)

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 29 Aug 2014 10:08:54 -0400

Hi Martin,

--On August 29, 2014 at 3:59:21 PM +0200 Martin Burnicki 
<[email-masked]> wrote:

>> 2. My proposal was for DNS to return *all* the timezone file when
>> receiving some sort of specialized query (which I hadn't determined),
>> rather than trying to return data for just one timezone.  Timezone data
>> needs to be usable "offline" and pulling the entire file is, in my
>> opinion, the best way to have an offline copy.
>
> I absolutely agree. +1

I disagree. There are obvious use cases where only one or two time zones 
might be needed. e.g., "internet of things" devices - my home thermostat 
only needs one time zone - namely the one where my house is. Such devices 
may have a limited memory capacity, and even though time zone data isn't 
huge, it would still be a waste to store it all when only one is being used.

-- 
Cyrus Daboo

---

From: Tim Parenti <[email-masked]>
Date: Fri, 29 Aug 2014 10:32:03 -0400

On 29 August 2014 10:08, Cyrus Daboo <[email-masked]> wrote:

> --On August 29, 2014 at 3:59:21 PM +0200 Martin Burnicki <
> [email-masked]> wrote:
>

I think both use cases are valid, and if we go the DNS route, it might be
wise to support both.  For now, though, I think that action (ticket #19)
has been deferred.
http://www.ietf.org/mail-archive/web/tzdist/current/msg00246.html
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/19

--
Tim Parenti

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 29 Aug 2014 10:51:13 -0400

Correction - I went back and found what I had originally written (some weeks
ago) but apparently never sent (?).   My idea was to have the files on the
NTP/SNTP servers, a more natural place for time-related data. The idea was
still the same, though - to allow an already existing distributed network of
servers to handle these.   I do agree with the point on "internet of things"
- however 'limited memory' is a lot larger these days than it used to be :-)

Tim Hare

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]] 
Sent: Friday, August 29, 2014 10:09 AM
To: Martin Burnicki; Tim Hare; 'Bradley White'; [email-masked];
[email-masked]
Subject: Re: [Tzdist] [calsify] Time Zone Distribution Protocol

Hi Martin,

-- 
Cyrus Daboo

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 29 Aug 2014 11:40:55 -0400

> huge, it would still be a waste to store it all when only one is being 

What he said.  All too often developers overlook resource-deprived devices. 
It's important to consider the impact on them to pull more data than 
necessary, to store it locally and to wade through it.  Bandwidth, CPU and 
storage are not free and means to be conservative about them ALWAYS be 
considered.

That and a spec that encourages means for brevity as the default should be 
considered.

Make it possible for all devices to get what someone configuring the domain 
considers to be "locally essential".   Don't let the examples cite 
'everything and the kitchen sink'.

-Bill Kearney

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 29 Aug 2014 11:44:13 -0400

Bear in mind the question "What will the client devices have 'on-hand' to go 
about making queries?"  Firmware may be quite limited.

Surely anything on a network is going to have a DNS client.  Is the same 
going to be true for NTP?  Not everything needs time, as there may be other 
processes/devices/whatever involved that handle time-related functionality.

-Bill Kearney

-----Original Message----- 
From: Tim Hare