Re: [calsify] Timezone Service Protocol not quite complete

[Cyrus Daboo <[e-mail]>]

Hi Steve,

--On November 7, 2013 at 11:03:53 AM -0500 Steve Crocker 
<[e-mail]> 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