Re: [calsify] Timezone Service Protocol not quite complete

[Steve Crocker <[e-mail]>]

Julian,

Thanks.  See responses in line.

Steve

On Nov 7, 2013, at 9:36 AM, Julian Cable <[e-mail]> wrote:

> Hi Steve,
> 
> I only noticed from your reply I had taken this off-list - that wasn't intentional. Shall we take it back-on?

Yes.  I wondered about that.  On the list is better, so I've taken the liberty of putting this on the list directly.

> I know what you mean. I'm not sure that quite matches reality. It feels to me like the "publishers" - governments in the main - don't care the slightest what happens when they change their minds. It is really end users and definitely broadcasters who would like the world to be more synchronised. As a broadcaster I'm interested in telling my audience when they can watch/listen to my programmes and having them not miss them by an hour. As a viewer and listener I'm interested in the same thing.

I understand your sense that governments do whatever they feel like, but they're not always capricious and often do try to understand how to do their job.  I think we have an opportunity here to set expectations, and I think we should do so.  As designers of the system, it's appropriate to us to tell the users how it works so they will know how to organize their activities.  The knowledgeable people in governments will be able to tell their superiors that it will take X amount of time to propagate the information, and system developers of end-user system will know how to set their parameters for making sure the data is up to date.

> As a traveller, I don't want to miss my plane.
> 
> I think that converges on the same requirement as your starting point. We do want low latency (hours not days) on late breaking changes. Of course most changes are signalled months ahead.

Agreed.

> For my use cases there is not much point asking things to propagate more quickly than an hour or two - flights and broadcast schedules can't be changed at such short notice and people can't be expected to have their wearable timepieces network connected during the appropriate interval.
> 
> So I guess one question is should the system be architected for the corner cases like Libya (and Bangladesh and Morocco), or the modal case where we get at least 30 days notice.
> 
> The current situation where it takes months or years for a server to happen to get updated is clearly wrong, and causes me real problems.
> 
> I would be comfortable with a global propagation time of 48 hours.

Hmm… Well, one way to deal with this is to use 48 hours and say any data more than 48 hours old is stale.  The main downside is very little actually changes that fast.  But at least that would set a definite bound.

Let me push a bit on the other thing I mentioned, the possibility of publishing this data via DNS.  Why not use DNS?  Or, at the very least, publish via DNS in addition to this protocol and see what happens.

Thanks,

Steve





> 
> Julian
> 
> -----Original Message-----
> From: Steve Crocker [mailto:[e-mail]] 
> Sent: 07 November 2013 13:47
> To: Julian Cable
> Cc: Steve Crocker
> Subject: Re: [calsify] Timezone Service Protocol not quite complete
> 
> Julian,
> 
> "High request rates" puts the emphasis on the load on the servers.  I think that's important but secondary.  The primary question, in my opinion, is how quickly the information about new time zone details should propagate.  Both the publishers and the end users need to know this.  The publisher wants to know how soon he can reasonably expect nearly everyone to have the information he publishes, and the end user wants to know whether his information is up to date.  Once those numbers are known, we can design the system to meet those requirements and we can understand what the load will be on the various servers, end systems, etc.
> 
> Steve
> 
> 
> 
> On Nov 7, 2013, at 4:34 AM, Julian Cable <[e-mail]> wrote:
> 
>> For a more recent example of a short notice change, see http://www.timeanddate.com/news/time/libya-cancels-dst-switch-2013.html.
>> 
>> Can we document a separate use case for the protocol? I understand high request rates are inappropriate for servers intending to propagate time zone changes, but the client use is quite appropriate in some circumstances and the protocol seems fine for this.
>> 
>> Julian
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Steve Crocker
>> Sent: 05 November 2013 22:39
>> To: IETF-Calsify
>> Subject: [calsify] Timezone Service Protocol not quite complete
>> 
>> I was very pleased to see the work on the Timezone Service Protocol.  I have no argument about the format of the data elements or actions, but the timing model is incomplete.  One of the motivations is make sure accurate timezone data is distributed in a timely fashion.  In order to make good on this, we need to say more about the timing.  As noted in the anecdote cited below, time zone changes are sometimes abrupt.  How much notice is required in order to make sure time zone changes are guaranteed to be propagated to all devices?  And on the other end of the system, how frequently do devices need to poll or otherwise be notified of changes?
>> 
>> Historically, IETF protocols have tended to be a bit vague about timing parameters and it's been left to operational practice.  The results are frequently messy.  We have a chance for this one to be much clearer.  The timezone database now maintained by IANA is a pretty solid solution for the source of reliable, authoritative information, but there's not been much written other than anecdotes about how often the data changes and how much lead time is required to distribute the information.
>> 
>> In the present draft, the only wording I could find is at the section 4.1.3:
>> 
>>> Clients SHOULD NOT poll for such changes too frequently, typically once a day ought to be sufficient.  See Section 8 on expected client and server behavior regarding high request rates.
>> 
>> and the cautions in Section 8.
>> 
>> I don't have an axe to grind regarding the design of the protocol, but I will note that if the timezone data were published via DNS, both the throttling problem and the model of propagation time would be dealt with automatically.  In any case, even if there's no desire to distribute this data over DNS, I do believe we need to provide much stronger statements about the expected time to propagate changes and to be clearer about how the design implements such statements.
>> 
>> Steve
>> 
>> 
>> 
>> 
>> On Oct 30, 2013, at 11:23 AM, Cyrus Daboo <[e-mail]> wrote:
>> 
>>> Hi [e-mail],
>>> 
>>> --On October 30, 2013 at 7:52:55 AM -0700 [e-mail] wrote:
>>> 
>>>>>> Which argues for including the local time when the event will take
>>>>>> place. If you want to mandate that the time also appear in UTC, great,
>>>>>> but it's quite important that the local time also be there.
>>>> 
>>>>> And local time should be normative to deal with such unforeseen
>>>>> circumstances as a papal visit.  From the southamerica file in the TZ
>>>>> database:
>>>> 
>>>>> # From Daniel C. Sobral (1998-02-12):
>>>>> # In 1997, the DS began on October 6. The stated reason was that
>>>>> # because international television networks ignored Brazil's policy on
>>>>> # DS, they bought the wrong times on satellite for coverage of Pope's
>>>>> # visit. This year, the ending date of DS was postponed to March 1
>>>>> # to help dealing with the shortages of electric power.
>>>> 
>>>>> ;-)
>>>> 
>>>> Good point. I agree.
>>> 
>>> Timezones can (and do) change at very short notice in different parts of the world. Typically computer systems have timezone data cached as part of the OS, and only get updates when the OS is itself updated - often long after a timezone change has occurred or long after future events were booked but are now out of sync for participants in different timezones. To address that a number of folks in the calendaring and scheduling community have been working om a timezone service protocol - <https://datatracker.ietf.org/doc/draft-douglass-timezone-service/> - our initial focus for that has been iCalendar (RFC5545) based VTIMEZONE component delivery to calendar and scheduling clients and servers. However, we would like to also deliver OS-style timezone data to devices to break out of the requirement for those to be updated only when the OS itself updates. For unix-based OS's that means being able to deliver "raw" zoneinfo" data over that protocol.
>>> 
>>> Anyway, if you are interested in that work please comment over on the ietf-calsify list (cc'd) - we (the authors of that draft) - intend to get it moving to last call soon. There are already several implementations that have undergone testing at the Calendaring and Scheduling Consortium (CalConnect) interop events, so we are happy with it, but would appreciate more feedback.
>>> 
>>> --
>>> Cyrus Daboo
>>> 
>> 
>> _______________________________________________
>> calsify mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/calsify
>> 
>> 
>> -----------------------------
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and
>> may contain personal views which are not the views of the BBC unless specifically stated.
>> If you have received it in
>> error, please delete it from your system.
>> Do not use, copy or disclose the
>> information in any way nor act in reliance on it and notify the sender
>> immediately.
>> Please note that the BBC monitors e-mails
>> sent or received.
>> Further communication will signify your consent to
>> this.
>> -----------------------------
> 
> 
> 
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and 
> may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in 
> error, please delete it from your system.
> Do not use, copy or disclose the 
> information in any way nor act in reliance on it and notify the sender 
> immediately.
> Please note that the BBC monitors e-mails 
> sent or received.
> Further communication will signify your consent to 
> this.
> -----------------------------