Subject: [Tzdist] I-D Action: draft-ietf-tzdist-service-02.txt

From: [email-masked]
Date: Fri, 17 Oct 2014 13:19:36 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Time Zone Data Distribution Service Working Group of the IETF.

        Title           : Time Zone Data Distribution Service
        Authors         : Michael Douglass
                          Cyrus Daboo
	Filename        : draft-ietf-tzdist-service-02.txt
	Pages           : 46
	Date            : 2014-10-17

Abstract:
   This document defines a time zone data distribution service that
   allows reliable, secure and fast delivery of time zone data to client
   systems such as calendaring and scheduling applications or operating
   systems.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tzdist-service-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tzdist-service-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tobias Conradi <[email-masked]>
Date: Fri, 17 Oct 2014 23:12:19 +0200

So, the does-not-exist-anywhere-else definition of "time zone" has been kept.

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

And the terminology texts are still not linkable and still without any
indication of a systematic approach distributed between section.
http://www.ietf.org/mail-archive/web/tzdist/current/msg00659.html

String counts related to the term "time zone" still give two digit
results for versions not having the word borders marked:
- timezone 53
- vtimezone 17
- timezones 16
- time-zone 0
- time_zone 0
which is an issue since before the WG was started.

There are more issues, but it is very *hard* to work with the document
if such fundamental flaws are not fixed.
-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Daniel Migault <[email-masked]>
Date: Wed, 22 Oct 2014 22:41:57 +0200

Dear Friends and Colleagues,

 I would like to get your feed backs on this version before the meeting. So
far I have only seen one comment from Tobias. I suppose, that other issues
have found consensus, however, I would appreciate you explicitly mention
you agree.

Given the open issues listed on here
<https://tools.ietf.org/wg/tzdist/trac/report/1> [1]. I would like to know
if you agree with version 02 or not. I suggest two ways to proceed:
    - 1) (prefered) Either you reply to the issue discussion, and provide
your feed back.
    - 2) You open a new thread and at least mention the issue number in the
subject.

BR,
Daniel

[1] https://tools.ietf.org/wg/tzdist/trac/report/1

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Oct 17, 2014 at 10:19 PM
Subject: [Tzdist] I-D Action: draft-ietf-tzdist-service-02.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Time Zone Data Distribution Service
Working Group of the IETF.

Abstract:

_______________________________________________
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: Wed, 22 Oct 2014 23:35:12 +0100

On 22/10/14 21:41, Daniel Migault wrote:
> <https://tools.ietf.org/wg/tzdist/trac/report/1> [1]. I would like to
> know if you agree with version 02 or not. I suggest two ways to proceed:
>     - 1) (prefered) Either you reply to the issue discussion, and
> provide your feed back.
>     - 2) You open a new thread and at least mention the issue number in
> the subject.

Many of the areas that *I* need to see supported have not even made it
into the draft. What IS in the draft complies with all of the
restrictions that the charter has created and will get something that
will probably then be used for another ten years, but does nothing to
address many of the real problems remaining.

Various options to handle historic data and manage accessing the correct
data in ten years time have been discussed, but none of it needs to be
added to the draft to comply with the charter? THAT is the problem here ...

Personally I'm probably better off simply ignoring tzdist and finishing
off an easily accessed version based access to the tz database, yet what
is being proposed needs so little to add the capabilities without making
it a requirement that a published produces anything other than a single
current set of data valid only from a date they decide on.

-- 
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: Tobias Conradi <[email-masked]>
Date: Thu, 23 Oct 2014 00:56:32 +0200

That I didn't make further comments on other issues, is only because I
think it is a waste of time. The basics of the document are a mess.
Not even the definition of "time zone" meets what ISO, IANA TZDB, and
laws of multi.zone countries give as definition of that term.

If the basics are fixed it might be much easier to address concerns
raised by Lester. For me it seems he is the only one that made
comments in that WG who also addressed larger design issues and thinks
in terms of reality and not in terms of the IANA TZDB, which only
provides a provenly false view of reality. The charter asks for
support of the IANA TZDB, but it does not ask for a design that only
fits with the IANA TZDB. The TZDIST charter allows for something
better.

I ask that the chairs work for fixing the basics of the document to
allow people to better discuss the other problems.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 23 Oct 2014 11:31:58 +0200

Daniel Migault wrote:
>   I would like to get your feed backs on this version before the
> meeting. So far I have only seen one comment from Tobias. I suppose,
> that other issues have found consensus, however, I would appreciate you
> explicitly mention you agree.

I'm working in software development but I'm mostly doing programming for 
embedded systems, driver software, and other low level stuff used in the 
context of time synchronization, so I'm not too familiar with HTTP, 
JSON, etc., and thus can't comment too much on the details of the 
protocol. However, I'm trying to see this from the point of view where 
you are working with this protocol.

I'm sure there are quite different types of applications where this new 
tzdist protocol is very helpful and very much appreciated, for example:

- Keeping appointments (e.g. iCalendar records) up to date, where you 
have to distinguish what happens to an appointment if the time zone 
rules change after the appointment has been made, e.g. you are going to 
have a phone call at a specified time vs. the departure/arrival times of 
a booked flight, which has been shortly discussed on the TZ mailing list 
recently.

- Working with historical data where you need to know the history of 
time zone rules

- A simple way to keep the time zone rules on computers, embedded 
devices and smartphones updated, where it may be practical for 
smartphones and embedded devices just to updated those time zones which 
are currently being used. In my opinion, on computers where several 
users can be logged in with different preferred time zones all time 
zones should be kept up to date, so whenever a user changes its 
preferred time zone there are current rules available.

I agree with Tobias that the wording in a document like this should be 
as unambiguous as possible. For example, in the text of some other 
standard which also discussed UTC and local time there was a term that 
something should happen "at midnight", without specifying whether 
"midnight" referred to UTC midnight or local time midnight. This 
probably leads to misunderstanding, confusion, and incompatible devices 
implemented by different folks.

Also, I'm not sure what exactly Lester is going to do with the tzdist 
protocol, but if some points are still missing in the definitions they 
should be added before the standard is released, otherwise there may be 
only limited acceptance of the new protocol, which would be a pity.

When reading the draft I also found a point what is still missing:

If you are going to work with historical data it might be important to 
know at which points in time leap seconds have been inserted into the 
UTC time scale, so it would be very helpful if the tzdist protocol would 
provide a way to distribute a list of leap seconds as provided by the 
NIST leap second file, or the leap second file included in the TZ data base.

Nowadays the NTP protocol is mostly used to synchronize time between 
computers and other devices. However, there's also the new Precision 
Time Protocol (PTP, IEEE 1588) which uses time stamps based on TAI, and 
is used more and more in new applications.

If you want to relate TAI to UTC at a given (current, or past) time you 
need to know *when* a leap second will be, or has been inserted in the 
UTC time scale.

So if this information could also be distributed via the tzdist protocol 
this would be very helpful for future interaction of systems based on 
TAI and UTC.

My only contribution to the wording of the draft is in chapter 7 which 
reads:

----------------------------------------------------------------------
7. JSON Definitions

    JSON members used by this specification are defined here using the
    syntax in [I-D.newton-json-content-rules].  Clients MUST ignore any
    JSON members they do not expect.
----------------------------------------------------------------------

Maybe a hint similar to "but they should/might generate a warning" 
should be appended. If a tzdist client receives a data set from a server 
which the client doesn't understand then this probably leads to 
mis-interpretation of the remaining data sets, and thus malfunction of 
the application.

Martin

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Oct 2014 13:53:15 +0200

On 10/23/14, 11:31 AM, Martin Burnicki wrote:
> UTC time scale, so it would be very helpful if the tzdist protocol
> would provide a way to distribute a list of leap seconds as provided
> by the NIST leap second file, or the leap second file included in the
> TZ data base.

This seems like a reasonable point, and I am opening an issue to track
it.  Proposals welcome to address this point.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Oct 2014 13:55:54 +0200

Lester,

Your message is not actionable.  If you have a technical issue that is
not already opened, raise it.  All technical issues must be addressed
before we send the draft forward.  That doesn't mean that everything
gets resolved the way you would like, but no issue should be ignored.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 13:26:46 +0100

> gets resolved the way you would like, but no issue should be ignored.

I'm not entirely sure under what ticket the management of supplying a
selectable historic view of tz data previously supplied is covered. It
is this area which I can't establish from the current draft? Apart from
the simple fact that it has no reason for being included under the charter?

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Oct 2014 14:38:34 +0200

I don't see why this is a charter discussion.  That seems like a valid
question.  We have discussed it in the past.  The question I believe
that remains is simply how selectable.  Please make a clear proposal
with proposed changes to the text.

Eliot

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 23 Oct 2014 15:01:30 +0200

Lester,

> the simple fact that it has no reason for being included under the charter?

I don't know how you evaluate historic data, and what exactly you expect 
from a "selectable historic view of tz data previously supplied".

I think my own approach would be to fetch the full set of time zone 
information, and then select from this set the data I need for my own 
work, so it's under my own control that the correct data have been selected.

If you leave the selection process to a server you can only rely on the 
server doing the selection properly, according to your expectations. 
Which types of selection should the server support, and what if you need 
a new type of selection which the server doesn't support, yet?

On the other hand, if you know some historic details on time zone rules 
you could submit them in the usual way, so they can be added to the main 
database and thus become available as an update via tzdist.

I hope I've understood correctly what you meant.

Martin

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 14:20:46 +0100

> I hope I've understood correctly what you meant.

No you haven't ...

It's has been documented on the list, but the scenario is quite easy to
describe. If I provide archived data that has been created using the
current set of timezone data and in ten years time someone is accessing
that data they need to be able to process the data using the SAME view
of the timezone data. This may well have changed so that the current
data set is different, and while 'changed_since' can say that there has
been a change, it provides no basis on which to access just what has
changed in the intervening 10 years. The user needs to be able to ask
for the correct view from ten years ago as they did not have that data
as a starting point with which to use the current data.

If we haven't built the handling of this into the standard now, then in
ten years time the historic data is unusable. Or we need a different
source of tz data that can be relied on in the future for that
application.

---

From: Stephen Colebourne <[email-masked]>
Date: Thu, 23 Oct 2014 14:28:10 +0100

I remain interested in issues 29 and 9, but I don't think I've got
anything to add to my previous comments.
Stephen

On 22 October 2014 21:41, Daniel Migault <[email-masked]> wrote:
> have found consensus, however, I would appreciate you explicitly mention you
> agree.
>
> Given the open issues listed on here [1]. I would like to know if you agree
> with version 02 or not. I suggest two ways to proceed:

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 23 Oct 2014 15:52:00 +0200

> source of tz data that can be relied on in the future for that

Agreed.

This sounds like a requirement for a revision control system ...

Martin

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 15:39:54 +0100

> This sounds like a requirement for a revision control system ...

http://hg.lsces.org.uk/hg/tzdata/
But it's not in a format that can be used to provide a usable timezone
data set easily

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 23 Oct 2014 10:46:40 -0400

Hi Lester,

--On October 23, 2014 at 2:20:46 PM +0100 Lester Caine <[email-masked]> 
wrote:

> If I provide archived data that has been created using the

OK, thank you. This is a nice clear statement of the issue. Please file a 
new ticket with the above text and lets start this thread afresh to discuss 
possible solutions.

-- 
Cyrus Daboo

---

From: Paul Eggert <[email-masked]>
Date: Thu, 23 Oct 2014 08:29:07 -0700

> it.  Proposals welcome to address this point.

The standard tz distribution has leap second information, and if we add 
its binary format as a media type it should all work.  Different 
distributions use different names for it, though; the default is the 
somewhat-awkward low-level naming convention 
TZ='../zoneinfo-leaps/America/Los_Angeles' to get Los Angeles time with 
leap seconds.  Presumably a better naming convention could be standardized.

(Sorry, I don't know how the issue tracker works.  If you've opened an 
issue and there's some standard way to add comments to it please copy 
the previous comment to it.)