Re: [calsify] PROPOSAL: TZID = Olson database Zone name

Cyrus Daboo <cyrus@daboo.name> Mon, 04 August 2014 15:19 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862061B2B5C for <calsify@ietfa.amsl.com>; Mon, 4 Aug 2014 08:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] 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 meUQ2m9dfoWc for <calsify@ietfa.amsl.com>; Mon, 4 Aug 2014 08:19:19 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C101B2B50 for <calsify@ietf.org>; Mon, 4 Aug 2014 08:19:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0C4454B1307; Mon, 4 Aug 2014 11:17:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIWcKCx2Qe0P; Mon, 4 Aug 2014 11:17:34 -0400 (EDT)
Received: from [10.0.1.22] (unknown [17.45.162.184]) by daboo.name (Postfix) with ESMTPSA id 1924E4B12F9; Mon, 4 Aug 2014 11:17:32 -0400 (EDT)
Date: Mon, 04 Aug 2014 11:19:11 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: alfiej@fastmail.fm, Ken Murchison <murch@andrew.cmu.edu>, calsify@ietf.org
Message-ID: <094FA782153195D4F06BAEAA@cyrus.local>
In-Reply-To: <1406764838.1326199.147492586.2D4C6DB5@webmail.messagingengine.com>
References: <1406763267.1318305.147484602.1D689093@webmail.messagingengine.com> <53D984E3.9090409@andrew.cmu.edu> <1406764838.1326199.147492586.2D4C6DB5@webmail.messagingengine.com>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2205"
Archived-At: http://mailarchive.ietf.org/arch/msg/calsify/bna4gFbnIAOczyBZQlLcSEKEa4A
Subject: Re: [calsify] PROPOSAL: TZID = Olson database Zone name
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 15:19:25 -0000

Hi Alfie,

--On July 30, 2014 at 8:00:38 PM -0400 Alfie John <alfiej@fastmail.fm> 
wrote:

> On Wed, Jul 30, 2014, at 07:50 PM, Ken Murchison wrote:
>> Are you proposing something like this:
>> http://tools.ietf.org/html/draft-daboo-caldav-timezone-ref-01
>
> Almost, but not quite. That RFC talks about applying to CalDAV but not
> for the actual payload e.g this RFC would have no affect on an iCalendar
> object within email attachments (e.g. iMIP).

That would be problematic because the Olson DB is one of several in common 
use right now. The other major one is, of course, the Microsoft Windows 
timezone DB. I don't think we can legitimately favor one over the other.

Note that the IETF is in the process of chartering a working group to 
define a timezone data distribution service 
(<http://datatracker.ietf.org/doc/charter-ietf-tzdist/>). One thing that is 
explicitly out of scope for that work is the "naming process for timezone 
identifiers". That statement was added precisely because it is a hard topic 
to get consensus on (e.g., there are a lot of people that feel that the 
"region/city" style Olson naming is wrong, and instead there should be 
"opaque" identifiers etc).

Now it may well be that once the WG completes the work it is chartered to 
do, it could revisit your issue - basically generalizing the CalDAV 
"timezones-by-reference" approach to be applicable to iCalendar as a whole. 
I think if we are going to do that, one option is to setup a new registry 
for timezone names (ones that do not use the "/" prefix). Provided there is 
no overlap between Olson DB and MS Windows DB names, we could register both 
sets and clients would be able to rely on those as "stable" identifiers - 
perhaps in conjunction with timezone data distribution services. Of course 
that is going to require buy-in by the entire community of timezone DB 
publishers as they will need to agree on using the registration service to 
avoid conflicts with others - or the registration process will need some 
way to disambiguate new TZ ids.

In any case, I suggest you participate in the new WG and bring this issue 
to its attention as a potential area that may need more work.

-- 
Cyrus Daboo