From Steve@shinkuro.com Tue Nov 5 14:39:05 2013 Return-Path: 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 6E22821E80D1 for ; Tue, 5 Nov 2013 14:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqHp8r1hiA8o for ; Tue, 5 Nov 2013 14:39:00 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id AAADF11E8103 for ; Tue, 5 Nov 2013 14:39:00 -0800 (PST) Received: from dummy.name; Tue, 05 Nov 2013 22:38:58 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steve Crocker In-Reply-To: <4FBA1270FC906838EB82345F@cc0102a-dhcp145.apple.com> Date: Tue, 5 Nov 2013 14:38:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: IETF-Calsify X-Mailer: Apple Mail (2.1499) Subject: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:39:05 -0000 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 wrote: > Hi ned+ietf@mauve.mrochek.com, >=20 > --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com = wrote: >=20 >>>> 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. >>=20 >>> And local time should be normative to deal with such unforeseen >>> circumstances as a papal visit. =46rom the southamerica file in the = TZ >>> database: >>=20 >>> # =46rom 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. >>=20 >>> ;-) >>=20 >> Good point. I agree. >=20 > 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 - = - = 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. >=20 > 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. >=20 > --=20 > Cyrus Daboo >=20 From Steve@shinkuro.com Thu Nov 7 07:25:50 2013 Return-Path: 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 BF46A21E8248 for ; Thu, 7 Nov 2013 07:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_20=-0.74, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDCyMUU+ABwS for ; Thu, 7 Nov 2013 07:25:45 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEB621E8235 for ; Thu, 7 Nov 2013 07:25:44 -0800 (PST) Received: from dummy.name; Thu, 07 Nov 2013 15:25:43 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steve Crocker In-Reply-To: <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> Date: Thu, 7 Nov 2013 10:25:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> To: Julian Cable , IETF-Calsify X-Mailer: Apple Mail (2.1499) Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:25:50 -0000 Julian, Thanks. See responses in line. Steve On Nov 7, 2013, at 9:36 AM, Julian Cable wrote: > Hi Steve, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > I would be comfortable with a global propagation time of 48 hours. Hmm=85 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 >=20 > Julian >=20 > -----Original Message----- > From: Steve Crocker [mailto:Steve@shinkuro.com]=20 > Sent: 07 November 2013 13:47 > To: Julian Cable > Cc: Steve Crocker > Subject: Re: [calsify] Timezone Service Protocol not quite complete >=20 > Julian, >=20 > "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. >=20 > Steve >=20 >=20 >=20 > On Nov 7, 2013, at 4:34 AM, Julian Cable = wrote: >=20 >> For a more recent example of a short notice change, see = http://www.timeanddate.com/news/time/libya-cancels-dst-switch-2013.html. >>=20 >> 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. >>=20 >> Julian >>=20 >> -----Original Message----- >> From: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On = Behalf Of Steve Crocker >> Sent: 05 November 2013 22:39 >> To: IETF-Calsify >> Subject: [calsify] Timezone Service Protocol not quite complete >>=20 >> 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? >>=20 >> 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. >>=20 >> In the present draft, the only wording I could find is at the section = 4.1.3: >>=20 >>> 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. >>=20 >> and the cautions in Section 8. >>=20 >> 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. >>=20 >> Steve >>=20 >>=20 >>=20 >>=20 >> On Oct 30, 2013, at 11:23 AM, Cyrus Daboo wrote: >>=20 >>> Hi ned+ietf@mauve.mrochek.com, >>>=20 >>> --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com = wrote: >>>=20 >>>>>> 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. >>>>=20 >>>>> And local time should be normative to deal with such unforeseen >>>>> circumstances as a papal visit. =46rom the southamerica file in = the TZ >>>>> database: >>>>=20 >>>>> # =46rom 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. >>>>=20 >>>>> ;-) >>>>=20 >>>> Good point. I agree. >>>=20 >>> 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 - = - = 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. >>>=20 >>> 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. >>>=20 >>> -- >>> Cyrus Daboo >>>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >>=20 >>=20 >> ----------------------------- >> 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. >> ----------------------------- >=20 >=20 >=20 > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and=20 > may contain personal views which are not the views of the BBC unless = specifically stated. > If you have received it in=20 > error, please delete it from your system. > Do not use, copy or disclose the=20 > information in any way nor act in reliance on it and notify the sender=20= > immediately. > Please note that the BBC monitors e-mails=20 > sent or received. > Further communication will signify your consent to=20 > this. > ----------------------------- From julian.cable@bbc.co.uk Thu Nov 7 07:40:44 2013 Return-Path: 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 9C3E521E80B9 for ; Thu, 7 Nov 2013 07:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.204 X-Spam-Level: X-Spam-Status: No, score=-8.204 tagged_above=-999 required=5 tests=[AWL=0.905, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6ZBH3jjZ9+z for ; Thu, 7 Nov 2013 07:40:40 -0800 (PST) Received: from mailout1.thls.bbc.co.uk (mailout1.thls.bbc.co.uk [132.185.240.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCB411E81E2 for ; Thu, 7 Nov 2013 07:40:32 -0800 (PST) Received: from BGB01XI1007.national.core.bbc.co.uk (bgb01xi1007.national.core.bbc.co.uk [10.161.14.21]) by mailout1.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id rA7FeG1A027185 for ; Thu, 7 Nov 2013 15:40:17 GMT Received: from BGB01XUD1011.national.core.bbc.co.uk ([169.254.10.114]) by BGB01XI1007.national.core.bbc.co.uk ([10.161.14.21]) with mapi id 14.02.0342.004; Thu, 7 Nov 2013 15:40:16 +0000 From: Julian Cable To: IETF-Calsify Thread-Topic: [calsify] Timezone Service Protocol not quite complete Thread-Index: AQHO2nfbtdTZ/UiBw0e3semc6wnkoJoZgfeAgABIsACAAAmTUIAAEhMAgAAAi6A= Date: Thu, 7 Nov 2013 15:40:15 +0000 Message-ID: <16E881F1666FAC4BA0C9DED580D711EC512913EE@BGB01XUD1011.national.core.bbc.co.uk> 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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> In-Reply-To: <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.14.18] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:40:44 -0000 Hi Steve, I wasn't setting 48 hours as any kind of "MUST". Just thinking out loud. A= month is too long. A minute is too short. I just had a quick look on the web and got back 48 hours as a typical ISP D= NS cache update interval. So it feels like a good match. I don't know where in DNS you are thinking of adding the data - it doesn't = feel like it fits in an DNS records I know of. -----Original Message----- From: Steve Crocker [mailto:Steve@shinkuro.com] Sent: 07 November 2013 15:26 To: Julian Cable; IETF-Calsify Cc: Steve Crocker Subject: Re: [calsify] Timezone Service Protocol not quite complete Julian, Thanks. See responses in line. Steve On Nov 7, 2013, at 9:36 AM, Julian Cable wrote: > Hi Steve, > > I only noticed from your reply I had taken this off-list - that wasn't in= tentional. Shall we take it back-on? Yes. I wondered about that. On the list is better, so I've taken the libe= rty of putting this on the list directly. > I know what you mean. I'm not sure that quite matches reality. It feels t= o me like the "publishers" - governments in the main - don't care the sligh= test what happens when they change their minds. It is really end users and = definitely broadcasters who would like the world to be more synchronised. A= s a broadcaster I'm interested in telling my audience when they can watch/l= isten to my programmes and having them not miss them by an hour. As a viewe= r and listener I'm interested in the same thing. I understand your sense that governments do whatever they feel like, but th= ey'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 tel= l 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 super= iors that it will take X amount of time to propagate the information, and s= ystem developers of end-user system will know how to set their parameters f= or 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 m= ost 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 chan= ged at such short notice and people can't be expected to have their wearabl= e timepieces network connected during the appropriate interval. > > So I guess one question is should the system be architected for the corne= r 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 happ= en 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 publis= hing this data via DNS. Why not use DNS? Or, at the very least, publish v= ia DNS in addition to this protocol and see what happens. Thanks, Steve > > Julian > > -----Original Message----- > From: Steve Crocker [mailto:Steve@shinkuro.com] > 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 thi= nk 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 wa= nts to know how soon he can reasonably expect nearly everyone to have the i= nformation he publishes, and the end user wants to know whether his informa= tion 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 wrote: > >> For a more recent example of a short notice change, see http://www.timea= nddate.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 zon= e changes, but the client use is quite appropriate in some circumstances an= d the protocol seems fine for this. >> >> Julian >> >> -----Original Message----- >> From: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On Beha= lf 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 t= imezone 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 require= d in order to make sure time zone changes are guaranteed to be propagated t= o all devices? And on the other end of the system, how frequently do devic= es 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 fre= quently messy. We have a chance for this one to be much clearer. The time= zone database now maintained by IANA is a pretty solid solution for the sou= rce of reliable, authoritative information, but there's not been much writt= en 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 throt= tling problem and the model of propagation time would be dealt with automat= ically. In any case, even if there's no desire to distribute this data ove= r DNS, I do believe we need to provide much stronger statements about the e= xpected time to propagate changes and to be clearer about how the design im= plements such statements. >> >> Steve >> >> >> >> >> On Oct 30, 2013, at 11:23 AM, Cyrus Daboo wrote: >> >>> Hi ned+ietf@mauve.mrochek.com, >>> >>> --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com wr= ote: >>> >>>>>> 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, grea= t, >>>>>> 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 o= n >>>>> # 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 o= f the world. Typically computer systems have timezone data cached as part o= f the OS, and only get updates when the OS is itself updated - often long a= fter a timezone change has occurred or long after future events were booked= but are now out of sync for participants in different timezones. To addres= s that a number of folks in the calendaring and scheduling community have b= een working om a timezone service protocol - - our initial focus for that has been= iCalendar (RFC5545) based VTIMEZONE component delivery to calendar and sch= eduling clients and servers. However, we would like to also deliver OS-styl= e 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 bei= ng able to deliver "raw" zoneinfo" data over that protocol. >>> >>> Anyway, if you are interested in that work please comment over on the i= etf-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 h= ave undergone testing at the Calendaring and Scheduling Consortium (CalConn= ect) interop events, so we are happy with it, but would appreciate more fee= dback. >>> >>> -- >>> Cyrus Daboo >>> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> 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 spe= cifically 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 spec= ifically 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 specif= ically 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. ----------------------------- From steve@shinkuro.com Thu Nov 7 07:46:26 2013 Return-Path: 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 96D1811E80DC for ; Thu, 7 Nov 2013 07:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWzez7Wvgz2k for ; Thu, 7 Nov 2013 07:46:12 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6E27421E8114 for ; Thu, 7 Nov 2013 07:46:12 -0800 (PST) Received: from dummy.name; Thu, 07 Nov 2013 15:46:12 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steve Crocker In-Reply-To: <16E881F1666FAC4BA0C9DED580D711EC512913EE@BGB01XUD1011.national.core.bbc.co.uk> Date: Thu, 7 Nov 2013 10:46:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC512913EE@BGB01XUD1011.national.core.bbc.co.uk> To: Julian Cable X-Mailer: Apple Mail (2.1499) Cc: IETF-Calsify Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:46:26 -0000 I haven't tried to work through the details yet but I would hope it = should be reasonably straightforward to pack this data into something = sensible within DNS and to choose an appropriate branch of the = hierarchy. It could either get its own second level domain, e.g. = "time-zone-data.org" or be published somewhere under iana.org. I don't = have any strong feelings about that as long as it's a domain name = everyone can count on for the indefinite future. The slightly harder question is how to format this data for DNS. I'll = take a quick look to see what it looks like. Steve On Nov 7, 2013, at 10:40 AM, Julian Cable = wrote: > Hi Steve, >=20 > I wasn't setting 48 hours as any kind of "MUST". Just thinking out = loud. A month is too long. A minute is too short. >=20 > I just had a quick look on the web and got back 48 hours as a typical = ISP DNS cache update interval. So it feels like a good match. >=20 > I don't know where in DNS you are thinking of adding the data - it = doesn't feel like it fits in an DNS records I know of. >=20 > -----Original Message----- > From: Steve Crocker [mailto:Steve@shinkuro.com] > Sent: 07 November 2013 15:26 > To: Julian Cable; IETF-Calsify > Cc: Steve Crocker > Subject: Re: [calsify] Timezone Service Protocol not quite complete >=20 > Julian, >=20 > Thanks. See responses in line. >=20 > Steve >=20 > On Nov 7, 2013, at 9:36 AM, Julian Cable = wrote: >=20 >> Hi Steve, >>=20 >> I only noticed from your reply I had taken this off-list - that = wasn't intentional. Shall we take it back-on? >=20 > Yes. I wondered about that. On the list is better, so I've taken the = liberty of putting this on the list directly. >=20 >> 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. >=20 > 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. >=20 >> As a traveller, I don't want to miss my plane. >>=20 >> 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. >=20 > Agreed. >=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> I would be comfortable with a global propagation time of 48 hours. >=20 > 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. >=20 > 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. >=20 > Thanks, >=20 > Steve >=20 >=20 >=20 >=20 >=20 >>=20 >> Julian >>=20 >> -----Original Message----- >> From: Steve Crocker [mailto:Steve@shinkuro.com] >> Sent: 07 November 2013 13:47 >> To: Julian Cable >> Cc: Steve Crocker >> Subject: Re: [calsify] Timezone Service Protocol not quite complete >>=20 >> Julian, >>=20 >> "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. >>=20 >> Steve >>=20 >>=20 >>=20 >> On Nov 7, 2013, at 4:34 AM, Julian Cable = wrote: >>=20 >>> For a more recent example of a short notice change, see = http://www.timeanddate.com/news/time/libya-cancels-dst-switch-2013.html. >>>=20 >>> 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. >>>=20 >>> Julian >>>=20 >>> -----Original Message----- >>> From: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On = Behalf Of Steve Crocker >>> Sent: 05 November 2013 22:39 >>> To: IETF-Calsify >>> Subject: [calsify] Timezone Service Protocol not quite complete >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> In the present draft, the only wording I could find is at the = section 4.1.3: >>>=20 >>>> 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. >>>=20 >>> and the cautions in Section 8. >>>=20 >>> 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. >>>=20 >>> Steve >>>=20 >>>=20 >>>=20 >>>=20 >>> On Oct 30, 2013, at 11:23 AM, Cyrus Daboo wrote: >>>=20 >>>> Hi ned+ietf@mauve.mrochek.com, >>>>=20 >>>> --On October 30, 2013 at 7:52:55 AM -0700 = ned+ietf@mauve.mrochek.com wrote: >>>>=20 >>>>>>> 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. >>>>>=20 >>>>>> And local time should be normative to deal with such unforeseen >>>>>> circumstances as a papal visit. =46rom the southamerica file in = the TZ >>>>>> database: >>>>>=20 >>>>>> # =46rom 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. >>>>>=20 >>>>>> ;-) >>>>>=20 >>>>> Good point. I agree. >>>>=20 >>>> 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 - = - = 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. >>>>=20 >>>> 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. >>>>=20 >>>> -- >>>> Cyrus Daboo >>>>=20 >>>=20 >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>>=20 >>>=20 >>> ----------------------------- >>> 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. >>> ----------------------------- >>=20 >>=20 >>=20 >> ----------------------------- >> 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. >> ----------------------------- >=20 >=20 >=20 > ----------------------------- > 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. > ----------------------------- > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From cyrus@daboo.name Thu Nov 7 07:55:34 2013 Return-Path: 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 C02D611E8168 for ; Thu, 7 Nov 2013 07:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cas27UL2Pd2y for ; Thu, 7 Nov 2013 07:55:27 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id C378C11E810F for ; Thu, 7 Nov 2013 07:55:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4E4D151A708C; Thu, 7 Nov 2013 10:55:26 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxOEWmzRj0I4; Thu, 7 Nov 2013 10:55:25 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id F366551A707B; Thu, 7 Nov 2013 10:55:23 -0500 (EST) Date: Thu, 07 Nov 2013 10:55:18 -0400 From: Cyrus Daboo To: Steve Crocker , Julian Cable , IETF-Calsify Message-ID: In-Reply-To: <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=3080 Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:55:35 -0000 Hi Steve, Thanks for your review and comments on the draft. --On November 7, 2013 at 10:25:42 AM -0500 Steve Crocker=20 wrote: >> I would be comfortable with a global propagation time of 48 hours. > > Hmm=E2=80=A6 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. Having chatted with co-authors, we agree with you that we need to tighten=20 up the language regarding clients and servers updating data. Our proposal=20 is as follows: - Servers that sync their data from other servers (aka local providers -=20 those identified as (d) in our Section 3 diagram) SHOULD check for updates=20 once per hour. - Clients (those identified as (e) in our diagram) SHOULD check for updates = once per day. If clients detect that their cached timezone data is out of=20 date (through some other out-of-band mechanism - e.g. by receiving a=20 VTIMEZONE component over email/iMIP - RFC6047) then they SHOULD immediately = attempt to resync their timezone cache. I will also add an example of the actual "refresh" HTTP request in Section=20 6.2. > 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. We certainly did consider DNS early on for this. However, there are a=20 number of reasons why we chose HTTP, including: - Many of today's existing calendaring and scheduling clients already do=20 HTTP via the CalDAV protocol (RFC4791) and HTTP apis are much easier to use = across multiple platforms than DNS apis. - Deployability - it is much faster to get widespread deployment of a web=20 service than it is of new DNS RR's etc. - Security - HTTPS is much more widely deployed and used than DNSSEC. - We want this to be an extensible "service" - i.e. we are doing more than=20 delivering "static" data. For example, the "expand" action is designed to=20 support lightweight clients doing calendaring - primarily webapps that=20 should not have to implement the full logic of recurrence rule expansion.=20 Also, we have plans for an extension whereby a client can ask the server to = tell it what range of dates are effected by a timezone change - this is=20 important in determining what events on a user's calendar might have to be=20 re-evaluated for scheduling conflicts. Another feature we want is=20 geo-location to timezone id mapping. Since we want to be able to deploy new = extensions quickly, HTTP beats DNS. Plus I really don't think we need to=20 overburden DNS with all the extra "apis" this would involve. That said, one piece we have (deliberately) not defined in our diagram in=20 Section 2 is how timezone data gets from "publishers" (e.g., IANA) to the=20 top-level providers (right now most people ftp/http download the data=20 package from IANA). That data is "static" and could quite easily be a put=20 into the DNS after some appropriate re-packaging. --=20 Cyrus Daboo From Steve@shinkuro.com Thu Nov 7 08:04:15 2013 Return-Path: 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 6176521E81AA for ; Thu, 7 Nov 2013 08:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMVUv3Tmuo3U for ; Thu, 7 Nov 2013 08:04:10 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id EF1D711E8168 for ; Thu, 7 Nov 2013 08:03:53 -0800 (PST) Received: from dummy.name; Thu, 07 Nov 2013 16:03:53 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steve Crocker In-Reply-To: Date: Thu, 7 Nov 2013 11:03:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3B13C12D-2F5B-446E-B439-028D6377DCD3@shinkuro.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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> To: Cyrus Daboo X-Mailer: Apple Mail (2.1499) Cc: IETF-Calsify Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:04:15 -0000 Cyrus, Thanks. A few comments in line. Steve On Nov 7, 2013, at 9:55 AM, Cyrus Daboo wrote: > Hi Steve, > Thanks for your review and comments on the draft. >=20 > --On November 7, 2013 at 10:25:42 AM -0500 Steve Crocker = wrote: >=20 >>> I would be comfortable with a global propagation time of 48 hours. >>=20 >> Hmm=85 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. >=20 > Having chatted with co-authors, we agree with you that we need to = tighten up the language regarding clients and servers updating data. Our = proposal is as follows: >=20 > - Servers that sync their data from other servers (aka local providers = - those identified as (d) in our Section 3 diagram) SHOULD check for = updates once per hour. >=20 > - Clients (those identified as (e) in our diagram) SHOULD check for = updates once per day. If clients detect that their cached timezone data = is out of date (through some other out-of-band mechanism - e.g. by = receiving a VTIMEZONE component over email/iMIP - RFC6047) then they = SHOULD immediately attempt to resync their timezone cache. >=20 > I will also add an example of the actual "refresh" HTTP request in = Section 6.2. >=20 >> 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. >=20 > We certainly did consider DNS early on for this. However, there are a = number of reasons why we chose HTTP, including: >=20 > - Many of today's existing calendaring and scheduling clients already = do HTTP via the CalDAV protocol (RFC4791) and HTTP apis are much easier = to use across multiple platforms than DNS apis. >=20 > - Deployability - it is much faster to get widespread deployment of a = web service than it is of new DNS RR's etc. The experience in creating new RRs is indeed problematic. I can't speak = for the folks who feel protective of DNS, but my inclination would be to = use TXT records and write a clear, simple and precise specification = about the structure of those TXT records. > - Security - HTTPS is much more widely deployed and used than DNSSEC. Getting the records signed shouldn't be a problem since that only = requires a single place to do it. Checking the signatures depends on = the implementations at each resolver. This will improve over time and = can be taken care via local initiative for anyone who feels it's = important. DNSSEC really is here. > - We want this to be an extensible "service" - i.e. we are doing more = than delivering "static" data. For example, the "expand" action is = designed to support lightweight clients doing calendaring - primarily = webapps that should not have to implement the full logic of recurrence = rule expansion. Also, we have plans for an extension whereby a client = can ask the server to tell it what range of dates are effected by a = timezone change - this is important in determining what events on a = user's calendar might have to be re-evaluated for scheduling conflicts. = Another feature we want is geo-location to timezone id mapping. Since we = want to be able to deploy new extensions quickly, HTTP beats DNS. Plus I = really don't think we need to overburden DNS with all the extra "apis" = this would involve. I don't know enough to speak to this yet. If I understand the intent, = it's a question of how the information is packaged inside of DNS whether = this is easy or hard to implement. > That said, one piece we have (deliberately) not defined in our diagram = in Section 2 is how timezone data gets from "publishers" (e.g., IANA) to = the top-level providers (right now most people ftp/http download the = data package from IANA). That data is "static" and could quite easily be = a put into the DNS after some appropriate re-packaging. >=20 > --=20 > Cyrus Daboo >=20 From cyrus@daboo.name Thu Nov 7 08:15:11 2013 Return-Path: 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 EDF3121E81C1 for ; Thu, 7 Nov 2013 08:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGP97VIfY5O0 for ; Thu, 7 Nov 2013 08:15:05 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 252E121E81A6 for ; Thu, 7 Nov 2013 08:15:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B388251A7641; Thu, 7 Nov 2013 11:15:04 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drMUZvLeGo8u; Thu, 7 Nov 2013 11:15:03 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id ABF3451A7634; Thu, 7 Nov 2013 11:15:02 -0500 (EST) Date: Thu, 07 Nov 2013 11:14:58 -0400 From: Cyrus Daboo To: Steve Crocker , Julian Cable , IETF-Calsify Message-ID: <7CF9F826B4E76A884F43F124@caldav.corp.apple.com> In-Reply-To: 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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2515 Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:15:11 -0000 Hi Steve, Julian, --On November 7, 2013 at 10:55:18 AM -0400 Cyrus Daboo wrote: > That said, one piece we have (deliberately) not defined in our diagram in > Section 2 is how timezone data gets from "publishers" (e.g., IANA) to the > top-level providers (right now most people ftp/http download the data > package from IANA). That data is "static" and could quite easily be a put > into the DNS after some appropriate re-packaging. I note that it is probably not clear from our diagram and description in the spec that we are not trying to cover the "contributor" -> "publisher" -> top-level "provider" piece. That is something I will fix for the next revision of the spec. --On November 7, 2013 at 10:46:12 AM -0500 Steve Crocker wrote: > I haven't tried to work through the details yet but I would hope it > should be reasonably straightforward to pack this data into something > sensible within DNS and to choose an appropriate branch of the hierarchy. > It could either get its own second level domain, e.g. > "time-zone-data.org" or be published somewhere under iana.org. I don't > have any strong feelings about that as long as it's a domain name > everyone can count on for the indefinite future. > > The slightly harder question is how to format this data for DNS. I'll > take a quick look to see what it looks like. It is worth noting that there are several data formats in use right now: - IANA package (the Olson data has "zone", "rule" and "link" data types which work together to define the rules for a single timezone) - VTIMEZONE as defined by iCalendar (RFC5545) - zoneinfo - used by most unix/linux-based systems for OS timezone data. This is typically generated from the IANA data - Windows registry - Microsoft maintains its own independent set of timezones with data sourced internally, and typically stored in the Windows registry. We certainly should be able to support Microsoft as a "publisher". Again, we deliberately did not address the "publisher" side of things because of the variety of options. However, our HTTP protocol does support content-negotiation via the "format" query parameter so it is possible to deliver timezone data in a variety of different formats in a fairly simple manner. We have already discussed the idea of writing a spec to formalize the zoneinfo format and give it a MIME type to make that possible. That is something we could do in conjunction with the IANA tz-database folks. -- Cyrus Daboo From julian.cable@bbc.co.uk Thu Nov 7 08:27:18 2013 Return-Path: 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 77E4511E80DC for ; Thu, 7 Nov 2013 08:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.251 X-Spam-Level: X-Spam-Status: No, score=-7.251 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxlwUmmZTyia for ; Thu, 7 Nov 2013 08:27:11 -0800 (PST) Received: from mailout0.thls.bbc.co.uk (mailout0.thls.bbc.co.uk [132.185.240.35]) by ietfa.amsl.com (Postfix) with ESMTP id 555A721E813E for ; Thu, 7 Nov 2013 08:27:08 -0800 (PST) Received: from BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) by mailout0.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id rA7GQqvd011607 for ; Thu, 7 Nov 2013 16:27:03 GMT Received: from BGB01XUD1011.national.core.bbc.co.uk ([169.254.10.114]) by BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) with mapi id 14.02.0342.004; Thu, 7 Nov 2013 16:26:58 +0000 From: Julian Cable To: IETF-Calsify Thread-Topic: [calsify] Timezone Service Protocol not quite complete Thread-Index: AQHO2nfbtdTZ/UiBw0e3semc6wnkoJoZgfeAgABIsACAAAmTUIAAEhMA///3ggCAAAV/AIAAEtWg Date: Thu, 7 Nov 2013 16:26:55 +0000 Message-ID: <16E881F1666FAC4BA0C9DED580D711EC51291540@BGB01XUD1011.national.core.bbc.co.uk> 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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> <7CF9F826B4E76A884F43F124@caldav.corp.apple.com> In-Reply-To: <7CF9F826B4E76A884F43F124@caldav.corp.apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.14.18] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:27:18 -0000 > It is worth noting that there are several data formats in use right now: Personally, I'd love it if you supported exactly one abstract syntax, and i= deally, exactly one concrete syntax. I'd rather parse JSON than rfc5545, but I'd rather have it your way than bo= th our ways. ----------------------------- 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 specif= ically 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. ----------------------------- From cyrus@daboo.name Thu Nov 7 08:33:14 2013 Return-Path: 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 5D9C721E8128 for ; Thu, 7 Nov 2013 08:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LwOfkOZhcTZ for ; Thu, 7 Nov 2013 08:33:09 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id C938421E8116 for ; Thu, 7 Nov 2013 08:33:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 655BE51A7DF4; Thu, 7 Nov 2013 11:33:07 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2Sroj20YyT3; Thu, 7 Nov 2013 11:33:06 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id B655751A7DE9; Thu, 7 Nov 2013 11:33:05 -0500 (EST) Date: Thu, 07 Nov 2013 11:33:01 -0400 From: Cyrus Daboo To: Julian Cable , IETF-Calsify Message-ID: <51D832A8E1FAFBF6D1D14816@caldav.corp.apple.com> In-Reply-To: <16E881F1666FAC4BA0C9DED580D711EC51291540@BGB01XUD1011.national.core.bbc.co.uk> 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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> <7CF9F826B4E76A884F43F124@caldav.corp.apple.com> <16E881F1666FAC4BA0C9DED580D711EC51291540@BGB01XUD1011.national.core.bbc.co.uk> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=694 Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:33:14 -0000 Hi Julian, --On November 7, 2013 at 4:26:55 PM +0000 Julian Cable wrote: >> It is worth noting that there are several data formats in use right now: > > Personally, I'd love it if you supported exactly one abstract syntax, and > ideally, exactly one concrete syntax. > > I'd rather parse JSON than rfc5545, but I'd rather have it your way than > both our ways. We do have jCal () which we will hopefully be finishing up work on now that jCard is done. I already tweaked my timezone service implementation to allow clients to request and receive jCal in addition to iCalendar formats. -- Cyrus Daboo From julian.cable@bbc.co.uk Thu Nov 7 08:37:31 2013 Return-Path: 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 56E0921E81B2 for ; Thu, 7 Nov 2013 08:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.088 X-Spam-Level: X-Spam-Status: No, score=-9.088 tagged_above=-999 required=5 tests=[AWL=1.511, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb2AF9gt56h0 for ; Thu, 7 Nov 2013 08:37:18 -0800 (PST) Received: from mailout1.thls.bbc.co.uk (mailout1.thls.bbc.co.uk [132.185.240.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8E21E8146 for ; Thu, 7 Nov 2013 08:37:08 -0800 (PST) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout1.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id rA7Gb7Pu012864 for ; Thu, 7 Nov 2013 16:37:07 GMT Received: from BGB01XUD1011.national.core.bbc.co.uk ([169.254.10.114]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.02.0342.004; Thu, 7 Nov 2013 16:37:07 +0000 From: Julian Cable To: IETF-Calsify Thread-Topic: [calsify] Timezone Service Protocol not quite complete Thread-Index: AQHO2nfbtdTZ/UiBw0e3semc6wnkoJoZgfeAgABIsACAAAmTUIAAEhMA///3ggCAAAV/AIAAEtWg///yNoCAABDzIA== Date: Thu, 7 Nov 2013 16:37:06 +0000 Message-ID: <16E881F1666FAC4BA0C9DED580D711EC512915FA@BGB01XUD1011.national.core.bbc.co.uk> 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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> <7CF9F826B4E76A884F43F124@caldav.corp.apple.com> <16E881F1666FAC4BA0C9DED580D711EC51291540@BGB01XUD1011.national.core.bbc.co.uk> <51D832A8E1FAFBF6D1D14816@caldav.corp.apple.com> In-Reply-To: <51D832A8E1FAFBF6D1D14816@caldav.corp.apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.14.18] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:37:31 -0000 I know. That is cool. I just hate standards that try to please too many peo= ple and offer so many options that no two implementations interoperate. This proposed standard is a long way from that. Let's keep it small. If Mic= rosoft or tz-list want to translate at the edge fine, but let's have a mini= mal set of choices on the wire. -----Original Message----- From: Cyrus Daboo [mailto:cyrus@daboo.name] Sent: 07 November 2013 15:33 To: Julian Cable; IETF-Calsify Subject: Re: [calsify] Timezone Service Protocol not quite complete Hi Julian, --On November 7, 2013 at 4:26:55 PM +0000 Julian Cable wrote: >> It is worth noting that there are several data formats in use right now: > > Personally, I'd love it if you supported exactly one abstract syntax, and > ideally, exactly one concrete syntax. > > I'd rather parse JSON than rfc5545, but I'd rather have it your way than > both our ways. We do have jCal () which we will hopefully be finishing up work on now that jCard is done. I already tweaked my timezone service implementation to allow clients to request and receive jCal in addition to iCalendar formats. -- Cyrus Daboo ----------------------------- 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 specif= ically 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. ----------------------------- From cyrus@daboo.name Thu Nov 7 08:40:35 2013 Return-Path: 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 2631021E813F for ; Thu, 7 Nov 2013 08:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teV8QXQpMGAD for ; Thu, 7 Nov 2013 08:40:28 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id F03A011E81E6 for ; Thu, 7 Nov 2013 08:40:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8FF0751A8015; Thu, 7 Nov 2013 11:40:24 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzOFIsaYwRUP; Thu, 7 Nov 2013 11:40:23 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 9403151A8001; Thu, 7 Nov 2013 11:40:22 -0500 (EST) Date: Thu, 07 Nov 2013 11:40:18 -0400 From: Cyrus Daboo To: Steve Crocker Message-ID: <40E66338A1D9BD1FD9E5EF9E@caldav.corp.apple.com> In-Reply-To: <3B13C12D-2F5B-446E-B439-028D6377DCD3@shinkuro.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> <16E881F1666FAC4BA0C9DED580D711EC51290824@BGB01XUD1011.national.core.bbc.co.uk> <971E6773-B1FB-414A-96C3-5775BC21C089@shinkuro.com> <16E881F1666FAC4BA0C9DED580D711EC5129122D@BGB01XUD1011.national.core.bbc.co.uk> <1C6AEFE0-27D4-4A5C-A357-E469D229510D@shinkuro.com> <3B13C12D-2F5B-446E-B439-028D6377DCD3@shinkuro.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2455 Cc: IETF-Calsify Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:40:35 -0000 Hi Steve, --On November 7, 2013 at 11:03:53 AM -0500 Steve Crocker wrote: >> - Deployability - it is much faster to get widespread deployment of a >> web service than it is of new DNS RR's etc. > > The experience in creating new RRs is indeed problematic. I can't speak > for the folks who feel protective of DNS, but my inclination would be to > use TXT records and write a clear, simple and precise specification about > the structure of those TXT records. VTIMEZONE data seems to typically be around 8KB for a complete (historical) definition (which is sometimes important to have rather than just the set of present and ongoing timezone data). I suspect that size will be problematic - though with the ever greater use of TXT those records have started getting larger and larger. >> - Security - HTTPS is much more widely deployed and used than DNSSEC. > > Getting the records signed shouldn't be a problem since that only > requires a single place to do it. Checking the signatures depends on the > implementations at each resolver. This will improve over time and can be > taken care via local initiative for anyone who feels it's important. > DNSSEC really is here. It is here but it will take a while for client-side apis to catch up to allow apps to evaluate the trust appropriately. >> - We want this to be an extensible "service" - i.e. we are doing more >> than delivering "static" data. For example, the "expand" action is >> designed to support lightweight clients doing calendaring - primarily >> webapps that should not have to implement the full logic of recurrence >> rule expansion. Also, we have plans for an extension whereby a client >> can ask the server to tell it what range of dates are effected by a >> timezone change - this is important in determining what events on a >> user's calendar might have to be re-evaluated for scheduling conflicts. >> Another feature we want is geo-location to timezone id mapping. Since we >> want to be able to deploy new extensions quickly, HTTP beats DNS. Plus I >> really don't think we need to overburden DNS with all the extra "apis" >> this would involve. > > I don't know enough to speak to this yet. If I understand the intent, > it's a question of how the information is packaged inside of DNS whether > this is easy or hard to implement. Packaging is one aspect, complexity of the types of query we might want to do is another. -- Cyrus Daboo