Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

Paul Eggert <eggert@cs.ucla.edu> Sun, 14 December 2014 18:28 UTC

Return-Path: <eggert@cs.ucla.edu>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F801A0119 for <tzdist@ietfa.amsl.com>; Sun, 14 Dec 2014 10:28:17 -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 3uOBkPK3wzVl for <tzdist@ietfa.amsl.com>; Sun, 14 Dec 2014 10:28:15 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id E42481A0118 for <tzdist@ietf.org>; Sun, 14 Dec 2014 10:28:15 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C4AD6A60019; Sun, 14 Dec 2014 10:28:15 -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 eHYczjIev4iH; Sun, 14 Dec 2014 10:28:11 -0800 (PST)
Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 361B7A60011; Sun, 14 Dec 2014 10:28:11 -0800 (PST)
Message-ID: <548DD6BA.80502@cs.ucla.edu>
Date: Sun, 14 Dec 2014 10:28:10 -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.3.0
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>, tzdist@ietf.org
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <5488921B.8020900@lsces.co.uk> <5488973F.7050400@andrew.cmu.edu> <54889C39.1080103@lsces.co.uk> <D2BE5C3BFE11019ECF4BEF62@caldav.corp.apple.com> <5488A6E6.8050903@lsces.co.uk> <CADC+-gTiyJ4QHZT6m3je9M9-ifSELnSWgmgy7iXSWNS+p8pthg@mail.gmail.com> <5488C0EA.8090505@lsces.co.uk> <CADC+-gTgckSe1ca6Sai6RguQid=ReM7bH6K8+dVVFm-YfbpFbA@mail.gmail.com> <5488DA56.2090306@lsces.co.uk> <CADC+-gQN=Qb2y8M-bHnPzMcK8r=xUG-seQ7XzvZwwcWsHpHnBQ@mail.gmail.com> <54895986.6060806@lsces.co.uk> <5489CA90.1070307@gmail.com> <35BC5886C9A58F866E8A46A8@caldav.corp.apple.com> <5489D9F7.3080207@gmail.com> <D196D63077FEC1B090DF7C86@caldav.corp.apple.com> <5489F79E.4080909@gmail.com> <BC19CC6916DC0E59CA63737D@caldav.corp.apple.com> <548B929C.3010505@gmail.com> <548C04F8.30005@lsces.co.uk> <D0F712C2A7EF425A8887E231@cyrus.local> <548C8535.5060508@cs.ucla.edu> <5F5A838C3A2D2B962EB84B92@cyrus.local>
In-Reply-To: <5F5A838C3A2D2B962EB84B92@cyrus.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/KlzCn2EkmMGjwZFu1dS56JVKSRM
Subject: Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Dec 2014 18:28:17 -0000

Cyrus Daboo wrote:
> ETag is something very specific to the HTTP protocol and is used in several
> ways - in particular it is important for caching by intermediaries etc.

Yes, and that's an argument for our using ETag instead of an 
application-specific versioning system.  Why reinvent a caching system when we 
can use HTTP's?

 > Plus
> there are reasons when you might want to refresh the client data in the absence
> of a publisher version upgrade (e.g., the tzdist server is using a more
> efficient, compact representation that it previously had).

That sounds fairly unusual, but if it happens, then the server could append 
something to the ETag, e.g., "tz2014j-format2" instead of plain "tz-2014j". 
That is, the ETag needn't be just the publisher version; it could be the 
publisher version plus the server format if the latter matters.

> HTTP has the concept of "strong" and "weak" ETags (see
> <http://tools.ietf.org/html/rfc7232#section-2.1>). It may be possible to make
> use of "weak" ETags for the version id.

Sure, and if people want to use weak ETags then they wouldn't need to mess with 
"-format2" suffixes.