Re: [calsify] Timezone Service Protocol not quite complete

[Cyrus Daboo <[e-mail]>]

Hi Steve,
Thanks for your review and comments on the draft.

--On November 7, 2013 at 10:25:42 AM -0500 Steve Crocker 
<[e-mail]> wrote:

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

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:

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

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

I will also add an example of the actual "refresh" HTTP request in Section 
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 
number of reasons why we chose HTTP, including:

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

- Deployability - it is much faster to get widespread deployment of a web 
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 
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.

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.

-- 
Cyrus Daboo