Re: [calsify] Timezone Service Protocol not quite complete

[Steve Crocker <[e-mail]>]

Cyrus,

Thanks.  A few comments in line.

Steve

On Nov 7, 2013, at 9:55 AM, Cyrus Daboo <[e-mail]> wrote:

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

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