Cyrus Daboo wrote:
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).
Yes. Although clients could omit etags, my guess is that it'd be OK in most cases privacy-wise to use them, so long as the etags are global (one per tz database version, e.g., "tz2015a") rather than per-server-and-database-version (e.g., "tz2015a-04F56E6866304E628CA1C45B"). That way, etags should provide little tracking info. A bonus is that a client could switch servers without having to re-get the tz database from the new server.
For the binary tz data format, I am not sure whether simply concatenating the binary data for all tzs is valid
It's not, unfortunately. Concatenation works for tzdata sources (so long as all identifiers are unique), but not for tzdata binaries. Operating system updates solve this by shipping tarballs, perhaps with some other info thrown in.
One thought is to add to the tz distribution, so that it also contains a single smallish source file that represents all the tz data. This file could be distributed via tzdist and clients could then run the equivalent of 'zic' to convert it to binary form, if that's what they want. This should be more compact than shipping binary files. The new source file would be in addition to the existing source files, which would not need to change (this is for backward compatibility to existing build procedures). This part should be fairly easy to arrange.
_______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
