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

Paul Eggert <eggert@cs.ucla.edu> Sun, 01 February 2015 21:29 UTC

Return-Path: <eggert@cs.ucla.edu>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509B61A1A9D; Sun, 1 Feb 2015 13:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TrOOF0Ap9cC; Sun, 1 Feb 2015 13:29:45 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC631A00F6; Sun, 1 Feb 2015 13:29:45 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 396B5A60052; Sun, 1 Feb 2015 13:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDBbP5RlSdRh; Sun, 1 Feb 2015 13:29:43 -0800 (PST)
Received: from [192.168.1.9] (pool-173-55-11-52.lsanca.fios.verizon.net [173.55.11.52]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id B08F9A60051; Sun, 1 Feb 2015 13:29:43 -0800 (PST)
Message-ID: <54CE9AC3.5060501@cs.ucla.edu>
Date: Sun, 01 Feb 2015 13:29:39 -0800
From: Paul Eggert <eggert@cs.ucla.edu>
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>, Lester Caine <lester@lsces.co.uk>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, saag@ietf.org, ietf-privacy@ietf.org, Eliot Lear <lear@cisco.com>
References: <CADZyTkkLu6qQ9LCqDkTHA9o+-YVvQuaUp33kqkAt=PRaQS-Jew@mail.gmail.com> <CADZyTkkCrvTam_ba7Tq6A-cHAVZn+ktKqwWsr_PNQaz2jyTkUQ@mail.gmail.com> <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> <54CC9DB3.6040500@lsces.co.uk> <54CD5886.7020409@cs.ucla.edu> <04F56E6866304E628CA1C45B@cyrus.local>
In-Reply-To: <04F56E6866304E628CA1C45B@cyrus.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-privacy/JeC14FUT3VrFK2aJVkJPH4cQif4>
Cc: Time Zone Data Distribution Service <tzdist@ietf.org>
Subject: Re: [ietf-privacy] [Tzdist] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Feb 2015 21:29:46 -0000

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.