Re: [Tzdist] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05

[Cyrus Daboo <[e-mail]>]

Hi Paul,

--On January 31, 2015 at 2:34:46 PM -0800 Paul Eggert <[e-mail]> 
wrote:

>> some devices such as central heating controllers
>> would not need a processor capable of the sort of processing power
>> needed to handle that
>
> Even the lowliest central heating controller can easily handle the entire
> tz database, if only to discard unneeded parts as they're received.
> We're talking kilobytes here, not gigabytes or even megabytes.

Well in this day and age the IETF really ought to also require an 
"Environmental Considerations" section in specs too, alongside "Security" 
and "Privacy". If that were a factor here (and I don't see why it would not 
be) then clearly sending all the data (and throwing away all but one) vs 
sending just one tz is an added impact on power usage for all devices 
involved (servers, clients, network hardware). Yes we are talking about 
kilobytes per device but you have to multiply that by the number of devices 
(which with internet of things is only going to increase beyond what we 
have now).

As with everything there are trade offs involved here. For a personal 
device, yes I do want strong privacy for key aspects of data that device 
might use (the obvious one being location information). However, for 
"fixed" devices, like a wall-clock in an office building, in all likelihood 
the exposure of revealing what time zone it is configure to use is likely 
small.

At this point I do think it worthwhile to give clients the option to chose 
what is appropriate for them given the trade offs. So it does make sense to 
provide a "full set of tz data" option in the protocol to allow clients to 
get the entire set of current data without exposing which specific time 
zone(s) they are actually interested in (which would also remove the need 
for them to use etags). How about a "getall" action using a /allzones URI 
to retrieve all the data. The only tricky part might be explaining how the 
data is returned. For iCalendar-based formats that is easy as multiple 
VTIMEZONEs would be included in a single VCALENDAR calendar object. For the 
binary tz data format, I am not sure whether simply concatenating the 
binary data for all tzs is valid - that is something that that format will 
need to be clear about.

-- 
Cyrus Daboo