Subject: Re: [Tzdist] [tzdist] #33 (service): “substantive” change

From: Daniel Migault <[email-masked]>
Date: Tue, 18 Nov 2014 12:50:45 +0100

Dear friends and Colleagues,

We are asking the WG whether Issue #33
<http://trac.tools.ietf.org/wg/tzdist/trac/ticket/33>: "substantive
changes" has been addressed by draft-ietf-tzdist-service-03
<http://tools.ietf.org/html/draft-ietf-tzdist-service-03>. Feel free to
give your opinion by Friday 21, so we can cleanup the open issue and focus
our attention on issues that have not been solved yet.

BR,
Daniel and Eliot

On Thu, Oct 23, 2014 at 9:44 PM, Lester Caine <[email-masked]> wrote:

> On 23/10/14 19:41, Tobias Conradi wrote:
> > The initial statement was
> >
> >>>> >>>A "material" change to the results of using a changed set of data
> must
> >>>> >>>be flagged, but anything that simply amends documentation does not
> need
> >>>> >>>any action to be made to review the effects of a change.
> > There are cases, where "correct new data" for something that not "
> > simply amends documentation" are irrelevant for some users.
> >
> > All data that a tower clock in Moscow does not need is irrelevant for
> > that tower clock. E.g.
> > - a change to historic data,
> > - a change to data after the next transition date,
> > - a change of TZID aliases
> > - a change of TZ names, other than the TZID that makes the connection
> > to the TZDIST, if any
>
> My current plan of attack for a system for building control in an
> apartment block would be simply to be using extract and monitoring the
> next DST change date. I currently envisage a local server which will
> provide a single TZID of data for the next period. The client devices
> will perhaps check each night and only get an update if the predicted
> offset has changed. I'm even thinking that a tzserver/local/ will give a
> single set of data for the building ... but it will probably actually
> provide the current time feed anyway so this is a little academic.
>
> If I am asking for any more than that data, then there should be some
> good reason, and any change within the truncation period asked for needs
> to be forwarded.
>
> As soon as one is asking for an 'un-truncated' view of the data, again
> any change in that data needs to be forwarded. If your tower clock asks
> for a full view of the data one supplies it even if it does not make
> sense. We do not know why the client needs it, so at the end of the day
> every change IS substantive if it is within the time period being
> requested. It may not be 'material' to a change of predicted offset, but
> it is material to the view of the data that was supplied initially.
>
> This does not mean I don't accept that some means of trimming the level
> of detail provide would be useful, but at present there is no documented
> method to include any supplementary data anyway? Only the core tz data ...
>
> --
> 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
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

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

---

From: Daniel Migault <[email-masked]>
Date: Sat, 22 Nov 2014 14:26:50 +0100

Dear Friends and Colleagues,

I believe this issue has reached WG consensus, and I am closing it.

BR,
Daniel

On Tue, Nov 18, 2014 at 12:50 PM, Daniel Migault <[email-masked]>
wrote:

>> >>>> >>>be flagged, but anything that simply amends documentation does
>> not need

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

---

From: "tzdist issue tracker" <[email-masked]>
Date: Sat, 22 Nov 2014 13:33:12 -0000

#33: “substantive” change

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-tzdist-
  [email-masked]       |  [email-masked]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  service      |     Version:
 Severity:  Active WG    |  Resolution:  fixed
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/33#comment:1>
tzdist <http://tools.ietf.org/tzdist/>