Re: [calsify] Timezone Service Protocol not quite complete

[Steve Crocker <[e-mail]>]

Bron, et al,

In response to your note about the charter and direction of the working
group, here's a note I sent more than five(!) years ago that garnered no
response at all.  Nonetheless, I think including some sort of expected
propagation time in the specification is -- or least ought to be -- within
scope.

Steve Crocker

On Tue, Nov 5, 2013 at 5:38 PM Steve Crocker <[e-mail]> wrote:

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