IETF Logo Mail Archive

Re: [Tzdist] [tzdist] #34 (service): should we include a raw tzdb format media type?

Ken Murchison <murch@andrew.cmu.edu> Thu, 08 January 2015 18:34 UTC

Return-Path: <murch@andrew.cmu.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 676981A0047 for <tzdist@ietfa.amsl.com>; Thu, 8 Jan 2015 10:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TExa8PMRirMe for <tzdist@ietfa.amsl.com>; Thu, 8 Jan 2015 10:34:52 -0800 (PST)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DAF1A0039 for <tzdist@ietf.org>; Thu, 8 Jan 2015 10:34:52 -0800 (PST)
Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id t08IYo2L026260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <tzdist@ietf.org>; Thu, 8 Jan 2015 13:34:51 -0500
Message-ID: <54AECDCA.4050308@andrew.cmu.edu>
Date: Thu, 08 Jan 2015 13:34:50 -0500
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: tzdist@ietf.org
References: <055.3273bd9c81e7cf06280617afb0cd8dc8@tools.ietf.org> <54ADC723.60707@cs.ucla.edu> <54AE15C6.10807@cisco.com> <54AE5700.2010505@lsces.co.uk> <54AEAC6F.7080406@cs.ucla.edu> <54AEB5D1.7020401@lsces.co.uk> <CAFpi07wcB=YHO-eTt3FYP=rN20v9gLDegqSQ11RUS7HDDGWKsA@mail.gmail.com>
In-Reply-To: <CAFpi07wcB=YHO-eTt3FYP=rN20v9gLDegqSQ11RUS7HDDGWKsA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.1.8.182419
X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_1099 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_URI_FOUND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0)
X-SMTP-Spam-Score: 33%
X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/xI671VK9wjD3eXqm1CohWe9LJxg>
Subject: Re: [Tzdist] [tzdist] #34 (service): should we include a raw tzdb format media type?
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: Thu, 08 Jan 2015 18:34:54 -0000

On 01/08/2015 01:21 PM, Tim Parenti wrote:
>
> That said, if a user requests a TZ binary file for a zone identifier 
> which is simply an alias, such as US/Eastern, I think it would be 
> perfectly reasonable for the server to return the corresponding file 
> for the linked zone — in this case, America/New_York. Whether the 
> response should also include some note about the "canonical" zone 
> name, I'm not sure.


For iCalendar data we note the "canonical" zone name by including a 
TZID-ALIAS-OF property in the data.

I'd have to look at RFC7231 to see if this is sane/legal, but an option 
for indicating the "canonical" zone name when fetching binary data for a 
linked zone might be to include a Content-Location response header with 
the URL to the "canonical" zone.

Another option would be to redirect a request for a linked zone (with 
the appropriate 3xx response code) to the "canonical" zone.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

v2.8.7 | Report a Bug | By Email