Re: [calsify] Timezone Service Protocol not quite complete

"Bron Gondwana" <brong@fastmailteam.com> Wed, 13 March 2019 04:45 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7412D826 for <calsify@ietfa.amsl.com>; Tue, 12 Mar 2019 21:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Level:
X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BG/BM1ba; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3H+Z6hZz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoIde_Ups4l7 for <calsify@ietfa.amsl.com>; Tue, 12 Mar 2019 21:45:37 -0700 (PDT)
Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846FA12AF80 for <calsify@ietf.org>; Tue, 12 Mar 2019 21:45:37 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 4EBC517A4B for <calsify@ietf.org>; Wed, 13 Mar 2019 00:45:34 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 13 Mar 2019 00:45:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=h5QaxZPBy2wS2oJvqEi3rdcZp5YX 2zxzHAwl3eVVPNY=; b=BG/BM1baDC39J1DN8eel9TOqnTjvi9yQuIlcL/bHGdJb Su9S7kXaE8cUh3qmJuAA9da3FRRKgrnzxhy37XxwIlX2D6rNXm3eJMGLFAdXSLZz 96SEenFwwoFx7AemWQcbM7vUdlZML5/kf87swI4cLpjXDOp1ZvhDRPyYt36xU1sA 7DsKjfEez3vZpoi8QLo9lduLO/GT6iHPYKp+CvBTe9SybmjmfyxX1U4JvWRcqJSm lCx4rpmEkka4x3qVEmHmN+AB0I/9mP0/zPUvC3kRIEVSBDRKwbWo5duXGx/OmgaS 1KNFfKvNRY7J5yaQzFpeLkXzlFls9AUkZpw+zGsKcw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=h5QaxZPBy2wS2oJvq Ei3rdcZp5YX2zxzHAwl3eVVPNY=; b=3H+Z6hZzzEwj6kKvf0rqtvw0PE8FWmdkV fGMl0yKAR3nffGUqKqSAzxUNGY/KvOsB74I3Ri0dYdyhRJxSxi2YDd9SByxIOAOw XgwrYzGYvlmxHTkWcoNv/yn6sG89TB9htSmjjf2PvlRuUvC9HXW8PurhUeJQtYp3 UlJMR6rXLBuWBldX6LQE4tk2xfauIGmOlM5dOpu4hAHfsnePX+XJzmWZV2TSLfgd 4XaFjSTZ2KY9mF6n/IBag7VvvN3GBBp5MpdHYOAjx+8jtr7D3w8MluTZRK4Jvdau /iFaLQmjZjbqOaIKlhNMO4W8cyR6ClXEmCaVFxB4vCYnGqzW2mKHA==
X-ME-Sender: <xms:7YqIXBBQycO7VhHkLawaW2Hw1ay2IyOmILeAyNOGAEyljIiXFkhi7Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgeelgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfthfevqddqufhushhpvggtthfgmhgrihhlohhrkf guqdffohhmrghinhculddutddtmdenucfjughrpefofgfkjghffffhvffutgesrgdtreer reertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrg hsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfr rghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:7YqIXLEdd686-5U5GQ9rGJINa2EfKZHfluWTrL0yMzFcSolZp5MljQ> <xmx:7YqIXMlGi2WRK0tquIjAaPKbKKV05L695_Mqt2wKwzQGhN9vv4YD2w> <xmx:7YqIXAutgu-wDQUC8236E32CZ8BUnKSgOtx13-ywtavhd5HV_j7wVg> <xmx:7oqIXBr_gSDwOIJ3nvVSvRmYBik2WT1G0zvCt5y2sRoZNjjuSR8sBg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id AA28D2058C; Wed, 13 Mar 2019 00:45:33 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5
X-Me-Personality: 56629417
Message-Id: <18c99085-7ab6-4df7-bab8-9b16520f216f@beta.fastmail.com>
In-Reply-To: <CADZyTknx-vfEuszPaTA7aOmpRLN5DBaUh==+FgNzqS76H1OoKw@mail.gmail.com>
References: <87879E7D-A55B-4A88-80B8-B503C89E52CB@iab.org> <20131030081355.GA23990@nic.fr> <7F135C08-A550-450F-82B4-1F239E115BC3@tzi.org> <20131030083611.GA27804@nic.fr> <01P06PWP9XG4004X76@mauve.mrochek.com> <527119E9.5050407@cisco.com> <01P06RD9XM60004X76@mauve.mrochek.com> <4FBA1270FC906838EB82345F@cc0102a-dhcp145.apple.com> <B52A13E8-A2E3-43F1-B036-EE3A64FE8C8A@shinkuro.com> <CABf5zv+Deh2fcD1PHh8PGTkZKYdRp=EDwZbSP67BXzHwDht4Gg@mail.gmail.com> <CADZyTknx-vfEuszPaTA7aOmpRLN5DBaUh==+FgNzqS76H1OoKw@mail.gmail.com>
Date: Wed, 13 Mar 2019 00:45:33 -0400
From: Bron Gondwana <brong@fastmailteam.com>
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary="758110d7e8d04cb7a83d4878f1b1a673"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/4l6U68J8mECQCqt-QQLyKZEX1_8>
Subject: Re: [calsify] Timezone Service Protocol not quite complete
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2019 04:45:40 -0000

Thanks Daniel - and thanks Steve for bringing this up. It was pinned for me to reply to, but I've been moving house over the last week, so not dealing with things quickly!

Shooting from the hip (I actually spent a while thinking about this while I was unpacking boxes) I would put a minimum bound of "once per day" and a maximum bound of "once per month" on how often devices should check for changes, with a sensible idea being something like: "once per week, on Friday".

Anyways, I certainly support adding this to the charter and talking about it in a more structured way rather than me guessing stuff.

Bron.

On Wed, Mar 13, 2019, at 11:17, Daniel Migault wrote:
> Thanks Steve for raising this point. Anyone opposed to add this item to the charter ? At least that would be good to provide guidance and quantification of the propagation so "best effort" becomes more specific. Please provide your thoughts on how we could probably address this on the mailing list.
> 
> Yours, 
> Daniel
> 
> On Fri, Mar 8, 2019 at 2:44 PM Steve Crocker <steve@shinkuro.com> wrote:
>> 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 <Steve@shinkuro.com> 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 <cyrus@daboo.name <mailto:cyrus@daboo...name>> wrote:
>>> 
>>>  > Hi ned+ietf@mauve.mrochek.com <mailto:ned%2Bietf@mauve.mrochek.com>,
>>>  > 
>>>  > --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com <mailto:ned%2Bietf@mauve.mrochek.com> 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
>>> calsify@ietf.org
>>> https://www.ietf.org/mailman/listinfo/calsify
>> _______________________________________________
>>  calsify mailing list
>> calsify@ietf.org
>> https://www.ietf.org/mailman/listinfo/calsify
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify
> 

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 brong@fastmailteam.com