Re: [apps-discuss] Proposed working group: Timezone Data Distribution Service (tzdist)

[Cyrus Daboo <[e-mail]>]

Hi Eliot,

--On June 22, 2014 at 1:13:50 PM +0200 Eliot Lear <[e-mail]> wrote:

>> Obviously there is a security implication from this approach: the IANA
>> data is signed as a whole (somewhat unofficially by the TZ
>> coordinator), but the individual timezone definitions derived from it
>> won't be signed by the same. So clients will need some form of
>> implicit trust in the top-level providers who do the conversion. But
>> that does bring up the question of whether the derived data pieces
>> should each be signed so that when they are delivered by secondary
>> servers, clients can verify they match what the top-level provider has
>> (I think this is what Patrik Fältström is suggesting in his response
>> (point 4).
>>
>
> Ok.  So scaling this doesn't fall on IANA's head, nor does IANA have to
> publish alternate formats, right?  If so, THAT should be made crystal
> clear in the charter.  So should the possibility that this group may ask
> for some adjustments to how data is signed by the TZ maintainer, if that
> is a possibility.  I'd suggest that the tz list be kept abreast of this.

How about adding the following text to the charter's "out of scope" section:

- Any changes to the IANA timezone database process or infrastructure, as 
documented in RFC 6557, other than recommendations for possible security 
enhancements.

>> - The timezone data distribution protocol should also offer an API to
>> allow thin clients to easily make use of timezone data by querying for
>> UTC offsets, offloading the sometimes complex work of expanding
>> recurrence rules to the service. This API should be extensible to
>> support other types of timezone operations in the future.
>
> To be clear, your starting point does not offer an API.  It is amenable
> to one, perhaps.  But that won't really be known until there is one.  I
> think you really meant "capability" and not "API".  Whether this is the
> same or different protocols is IMHO an important design question that
> should be decided now, and I'm glad you've asserted a proposal.  In
> looking at draft-douglass-timezone-service it requires a pretty fully
> understanding of CalDAV.  Is that indeed appropriate for a thin client?

No - the current draft has no dependency on CalDAV whatsoever - in fact 
CalDAV is not mentioned in the draft at all. 
draft-daboo-caldav-timezone-ref does discuss how to incorporate the 
timezone distribution service into CalDAV to improve performance and 
reliability there.

As I mentioned in a reply to Patrik Fältström, the initial impetus for 
this work came from the discovery that several web calendar implementations 
had written their own timezone service to provide "thin client" timezone 
expansion apis. In addition to improving the overal distribution process, 
providing for such an api should be a key requirement - though as you point 
out there is the possibility it could be decoupled from the distribution 
piece.

> To a lesser extent I have concerns about this statement:
>
>>  The timezone data distribution protocol should be "web friendly" to
>> allow browser-based calendar clients easy access to the data and API.
>
> This seems to be a "let's do it in JSON" requirement.  IMHO there is
> little need for this statement, given the starting point.

OK, that point is probably redundant given the one preceding it, and can be 
removed.

-- 
Cyrus Daboo