Subject: Re: [Tzdist] [tzdist] #16 (service): draft-ietf-tzdist-service: definition of "substantive" in Section 4.1.3

From: "tzdist issue tracker" <[email-masked]>
Date: Thu, 23 Oct 2014 14:46:43 -0000

#16: draft-ietf-tzdist-service: definition of "substantive" in Section 4.1.3

Changes (by [email-masked]):

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

Old description:

> Section 4.1.3's definition of "substantive" change is too strict. For
> example, the tz database's 2014f release changed Australian time zone
> abbreviations and for some applications this change could reasonablyb be
> considered "substantive".  I suggest loosening the definition by using
> the following wording instead:
>
>    Any change that affects the calculated UTC offsets for a timezone is a
> "substantive" change.  Other changes, such as changes to descriptions,
> may be treated as "substantive" changes.

New description:

 Section 4.1.3's definition of "substantive" change is too strict. For
 example, the tz database's 2014f release changed Australian time zone
 abbreviations and for some applications this change could reasonablyb be
 considered "substantive".  I suggest loosening the definition by using the
 following wording instead:

    Any change that affects the calculated UTC offsets for a timezone is a
 "substantive" change.  Other changes, such as changes to descriptions, may
 be treated as "substantive" changes.

 Section 4.1.3 of version 02 specifies:

 """A "substantive" change is one which affects the calculated onsets for
    a time zone.  Changes to properties such as a description are not
    treated as a "substantive" change."""

 The text of version 02 reflects the consensus of the WG. As such, I am
 considering this issue fixed. Feel free to respond if you do not agree.

--

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

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

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 23 Oct 2014 16:59:01 +0200

> #16: draft-ietf-tzdist-service: definition of "substantive" in Section 4.1.3
...
>  considering this issue fixed. Feel free to respond if you do not agree.

https://www.ietf.org/rfcdiff?url1=draft-ietf-tzdist-service-01&difftype=--html&submit=Go%21&url2=draft-ietf-tzdist-service-02

gives no change for 4.1.3 other than
OLD from even year-to-year
NEW during the course of a year

Also, if you would have not ignored emails sent to the WG mailing
list, then you would see there is no consensus to keep "substantive".

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

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

Hi Tobias,

--On October 23, 2014 at 4:59:01 PM +0200 Tobias Conradi 
<[email-masked]> wrote:

> https://www.ietf.org/rfcdiff?url1=draft-ietf-tzdist-service-01&difftype=-
> -html&submit=Go%21&url2=draft-ietf-tzdist-service-02
>

Not ignored  - more like lost track of. I created a ticket to track this: 
<http://trac.tools.ietf.org/wg/tzdist/trac/ticket/33>. In fact I had been 
thinking about this and discussed with co-author Mike, and I think we came 
to the conclusion that we should do away with "substantive" and just treat 
any change, no matter how minor, as triggering a "changedsince" response 
for the corresponding tzid.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 23 Oct 2014 17:38:02 +0200

On Thu, Oct 23, 2014 at 5:11 PM, Cyrus Daboo <[email-masked]> wrote:

> any change, no matter how minor, as triggering a "changedsince" response for
> the corresponding tzid.

My proposal how to replace "substantive" was at

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

and was related to Ticket #16. If now a new ticket is created, then
maybe a link pointing to Ticket #33 should be added to Ticket #16. The
other possibility would be to merge #33 into #16.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 23 Oct 2014 12:06:38 -0400

Hi Tobias,
(Trimming cc list to just the mailing list)

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

So a "field" level synchronization is much more complicated to do in the 
protocol and I would prefer not to have that. Instead just requiring every 
change to trigger "a "changedsince" response will allow the client to 
download the new data and decide for itself what it wants to do with it 
(e.g., if it spots there is no actual time-related changes - just a name 
change - then it won't need to trigger changes in events referencing that 
tzid).

Ticket #16 was closed - so we should just use #33 for the ongoing 
discussion of this.

-- 
Cyrus Daboo