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

From: Cyrus Daboo <[email-masked]>
Date: Mon, 04 Aug 2014 11:19:11 -0400

Hi Alfie,

--On July 30, 2014 at 8:00:38 PM -0400 Alfie John <[email-masked]> 
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