Subject: Re: [Tzdist] Ticket #16

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Sep 2014 14:54:46 +0200

Dear friends and colleague,

Looking at ticket #16 I expected to find the following text in section
4.1.3.:

"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."

I do not see any changed in section 4.1.3. My question is: do we expect to
see this text in version 02 or not.

BR,
Daniel

On Wed, Aug 27, 2014 at 2:47 PM, Tobias Conradi <[email-masked]>
wrote:

> On Wed, Aug 27, 2014 at 2:29 PM, Eliot Lear <[email-masked]> wrote:
> > Tobias,
> >
> > On 8/27/14, 1:57 PM, Tobias Conradi wrote:
> >> On Wed, Aug 27, 2014 at 11:16 AM, Lester Caine <[email-masked]>
> wrote:
> >>>> Get data that has changed in field <field name>
> >>> There is nothing in the protocol that allows this to happen. ALL one
> can
> >>> do is 'get' all of the data fields the server is providing.
> >> Then I propose to fix that deficiency. Then at least Service users can
> >> predict the return output instead of having to rely on what a provider
> >> deems "substantive".
> >
> > What we are talking about here are machine readable entries, and not
> > entries that are given in a particular spoken language.
> Can you give substance to your claims?
>
> >  And so I don't
> > see a possible benefit to the user.
> - by my proposal to fix, or
> - by the current implementation, or
> - by the proposal in trac?
>
> >  As to the reference you gave to
> > anna.info, should someone want to organize a database in that way, the
> > protocol should support retrieval by those keys.  You haven't called for
> > any changes along those lines.
> I did, by asking for "Get data that has changed in field <field name>".
>
> Database design is out of scope of the charter. So I suggested a
> general way to restrict "changedsince"-output.
>
>
> --
> Tobias Conradi
> Rheinsberger Str. 18
> 10115 Berlin
> Germany
>
> http://tobiasconradi.com
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

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

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 24 Sep 2014 10:43:14 -0400

Hi Daniel,

> see this text in version 02 or not.

I had been holding off a bit on tackling this one until some of the other 
big issues were out of the way.

The discussion so far on this topic has indicated to me that what is 
considered "substantive" is really something that is going to be client 
dependent - some clients may only care about a subset of the properties of 
a time zone. We have already discussed the possibility of an enhanced 
protocol that would allow clients to "filter" the data they get and thus 
define what is "important" to then that way. However, I think such an 
approach is complicated and should not be in the base spec.

Right now I am tempted to drop the "substantive" change text entirely and 
require that any change to the tz data should result in the dtstamp change 
and thus result in tht tz being returned in a "changedsince" response. That 
may mean some clients will be forced to refetch data that actually results 
in no change on their end - but we can have an extension to optimize for 
that if the need arises.

So my proposal is this:

1) Drop the third paragraph of section 4.1.3 (the definition of 
"substantive")
2) Adjust the second paragraph of section 4.1.3 to not use "substantive", 
but instead indicate any change to the data will trigger a changedsince 
response.

And we should probably add a page to the wiki listing various extensions 
that we have discussed so we can track those for any future work.

-- 
Cyrus Daboo

---

From: Tim Parenti <[email-masked]>
Date: Wed, 24 Sep 2014 10:47:51 -0400

On 24 September 2014 10:43, Cyrus Daboo <[email-masked]> wrote:

> We have already discussed the possibility of an enhanced protocol that
> would allow clients to "filter" the data they get and thus define what is
> "important" to then that way. However, I think such an approach is
> complicated and should not be in the base spec.
>

Agreed.

> but instead indicate any change to the data will trigger a changedsince

All of this seems reasonable to me.

--
Tim Parenti

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Sep 2014 10:48:54 -0400

+1

On 09/24/2014 10:47 AM, Tim Parenti wrote:
>
> On 24 September 2014 10:43, Cyrus Daboo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     We have already discussed the possibility of an enhanced protocol
>     that would allow clients to "filter" the data they get and thus
>     define what is "important" to then that way. However, I think such
>     an approach is complicated and should not be in the base spec.
>
>
> Agreed.
>
>     So my proposal is this:
>
>     2) Adjust the second paragraph of section 4.1.3 to not use
>     "substantive", but instead indicate any change to the data will
>     trigger a changedsince response.
>
>

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Daniel Migault <[email-masked]>
Date: Wed, 24 Sep 2014 16:51:33 +0200

+1

On Wed, Sep 24, 2014 at 4:48 PM, Ken Murchison <[email-masked]> wrote:

> Tzdist mailing [email-masked]://www.ietf.org/mailman/listinfo/tzdist
>
>
>
> --
> Kenneth Murchison

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

---

From: Lester Caine <[email-masked]>
Date: Wed, 24 Sep 2014 16:02:58 +0100

God I hate these crappy phone clients ...
Changes will depend on the level of content actually supplied by the publisher, so Yes initially any change is flagged. Providing a subset of changed data would come later if required.

Sent from my android device so the quoting is crap!

---

From: Dave Thewlis <[email-masked]>
Date: Wed, 24 Sep 2014 09:43:46 -0700

+1

On Sep 24, 2014, at 7:51 AM, Daniel Migault <[email-masked]> wrote:

>> We have already discussed the possibility of an enhanced protocol that would allow clients to "filter" the data they get and thus define what is "important" to then that way. However, I think such an approach is complicated and should not be in the base spec.
>>  
>> Agreed.
>> 
>> So my proposal is this:
>> 
>> 1) Drop the third paragraph of section 4.1.3 (the definition of "substantive")
>> 2) Adjust the second paragraph of section 4.1.3 to not use "substantive", but instead indicate any change to the data will trigger a changedsince response.
>> 

--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | [email-masked]