On 01/02/15 20:03, Cyrus Daboo 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.
This is actually a good point. One of the 'cost cutting' exercises IS to eliminate the need for a mains power supply since modern devices need so little power so while power over the network cable is a more recent 'development', many current central heating controllers have a couple of AA batteries and a not to 'replace every few years'. So adding paper displays, they can go to sleep for most of the time and any unnecessary software cycles are a drain :) > 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. One thing that I have only just twigged is that what we are talking about here is just sending the one data package with everything in! If something is not spelt out it is often missed. I still see the 'power saving' capabilities of a 'changed since' data package flagging centrally just which TZis's need to be looked at, and a complete diff package rather than a full dump again would reduce packet size, but there is no security risk from that either way? I still see the major advantage of tzdist in it's ability to flag that something needs looking at. If I'm not following the affected TZid's then it's up to me if I even update, but I only really see that being necessary if there are several competing publishers each using their own set of data for some 'political or commercial' reason so while we select a default local one, third party material may well need our accessing other services :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk _______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
