Subject: Re: [Tzdist] Ticket #22

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Sep 2014 10:11:46 +0200

Hi Paul,

I apology for not having responded to that your mail.

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.

I agree. By data, I meant the data of the Time Zone DB, not the VTIMEZONE
data.

On Thu, Aug 28, 2014 at 10:45 PM, Paul Eggert <[email-masked]> wrote:

> Daniel Migault wrote:
>
>> My understanding is is that it may not address all use cases, but most of
>> 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
>> format which is another topic.
>>
>
> 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.
>

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

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Sep 2014 10:27:19 +0200

So my understanding is that unless the time zone is removed, can be handled
by "ETag" and "changedsince".

If the time zone is removed, this issue is being addressed by qualifying
the change of substantive and an appropriated alias policy when a time zone
is removed. qualification of substantive is addressed by [Issue#16] and the
removal of a zone is addressed by [Issue#18].

The text for [Issue#16] and [Issue#18] seems to have reached consensus. I
propose to close [Issue#22] as it is addressed by [Issue#16] and
[Issue#18]and close [Issue#16] and [Issue#18] when the text will be
published in version 02.

BR,
Daniel

On Fri, Aug 29, 2014 at 2:39 AM, Cyrus Daboo <[email-masked]> wrote:

> Hi Paul,
>
> --On August 28, 2014 at 2:42:48 PM -0700 Paul Eggert <[email-masked]>
> wrote:
>
>  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,
>>>
>>
>> That approach would seem to rely on two assumptions that aren't in the
>> spec.
>>
>
> 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
>
>

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

---

From: Paul Eggert <[email-masked]>
Date: Fri, 26 Sep 2014 02:00:01 -0700

> [Issue#18]and close [Issue#16] and [Issue#18] when the text will be

I'm afraid I am having trouble understanding this suggestion, since I don't know 
what "[Issue#18]" stands for.  (It'd be helpful if questions like the above came 
with URLs that people could read in order to figure out what is intended.)

Anyway, as I recall some people felt that a publisher or server should never 
withdraw a name, whereas others felt that withdrawn names were a common practice 
and it's not tzdist's job to prohibit it.  Did we ever reach a consensus on that?

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Sep 2014 11:27:21 +0200

On Fri, Sep 26, 2014 at 11:00 AM, Paul Eggert <[email-masked]> wrote:

> I'm afraid I am having trouble understanding this suggestion, since I
> don't know what "[Issue#18]" stands for.  (It'd be helpful if questions
> like the above came with URLs that people could read in order to figure out
> what is intended.)
>
> I apology, here are the links:
    - [Issue#18] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/18
    - [Issue#22] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/22

Anyway, as I recall some people felt that a publisher or server should
> never withdraw a name, whereas others felt that withdrawn names were a
> common practice and it's not tzdist's job to prohibit it.  Did we ever
> reach a consensus on that?

My understanding is that we reached consensus on the following text that
warns publishers of consequences from removing a zone [Issue#18]
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/18. tzdist at least
discourage such practice but  does not prohibit them.

"""
 If a time zone X is deleted, it is common for a publisher to make its
 identifier an alias for some other time zone Y, to cater to clients
 that may still be using X's identifier; because this changes Y, it can
 be discovered by a "list" with "changedsince".  In contrast, the
 outright deletion of X (with no other change) requires a "list"
 without "changedsince" to be discovered.

 It is common for clients to silently substitute UTC for withdrawn or
 unknown time zone names.
"""

> _______________________________________________
> 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: Fri, 26 Sep 2014 10:51:36 +0100

On 26/09/14 10:27, Daniel Migault wrote:
> warns publishers of consequences from removing a zone
> [Issue#18] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/18. tzdist
> at least discourage such practice but  does not prohibit them.
> 
> """

I still object to this hack!
'silently substitute' anything other than retaining the current offset
is not a practical approach for simple systems. If it is forced to
change then it should not be 'silent' and should warn of the change!

But I do think that moving forward, the server used by simple systems is
what will control this so to some extent one can totally ignore what the
standard does anyway. I'm actually looking now at server on a local
distributed system providing a URL which furnishes a 'default' set of
data for a single TZID so we don't have to program every client device
with a selection at all. The server can still then provided a full set
of data for all of the other devices on the local area without having to
use bandwidth to an external service other than to get updates. THIS is
how I see distributed systems developing in the future.

-- 
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: Fri, 26 Sep 2014 14:47:09 +0200

On Fri, Sep 26, 2014 at 11:27 AM, Daniel Migault <[email-masked]> wrote:
>> don't know what "[Issue#18]" stands for.  (It'd be helpful if questions like
>> the above came with URLs that people could read in order to figure out what
>> is intended.)
>>
>> common practice and it's not tzdist's job to prohibit it.  Did we ever reach
>> a consensus on that?
>
>

Your understanding is wrong.

withdrawn time zone names? What are time zone names to begin with?

The glossary says, a time zone is
"A description of the historical and predicted timekeeping
practices of a collection of clocks that are intended to agree;"

Where is the evidence that
- several publishers exist that define a time zone in that manner?
- among those publishers several delete time zones
- among the latter it is common to use the identifier of the deleted
as an alias for another time zone

' /because this changes Y/, it can be discovered by a "list" with
"changedsince" '

>From http://tools.ietf.org/id/draft-ietf-tzdist-service-01.txt
' If the "changedsince" query parameter is present its value MUST
      correspond to a previously returned timestamp value. '

Which "previously returned timestamp value" shall the user of X use here?

And why is it suggested to use a "list" action, if all the user of X
cares about is one time zone?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com