Re: Registration of media type application/calendar+xml

Cyrus Daboo <cyrus@daboo.name> Fri, 10 September 2010 13:40 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A5D3A6403 for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 06:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.433
X-Spam-Level:
X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1FHimaNlDGa for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 06:40:27 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 5D81E3A67E5 for <IETF@ietf.org>; Fri, 10 Sep 2010 06:40:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6177A1923FF40; Fri, 10 Sep 2010 09:40:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u9kD7r3YgWG; Fri, 10 Sep 2010 09:40:48 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 4394F1923FF33; Fri, 10 Sep 2010 09:40:46 -0400 (EDT)
Date: Fri, 10 Sep 2010 09:40:43 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Tony Finch <dot@dotat.at>, Keith Moore <moore@cs.utk.edu>
Subject: Re: Registration of media type application/calendar+xml
Message-ID: <E55C49EE37FE8DB65855B19B@caldav.corp.apple.com>
In-Reply-To: <21461_1284104520_o8A7fxBr026679_F51F0DFC-FC12-4F1A-A0E2-B5119FF446FA@dotat.at>
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu> <B0EA09C87A5701A94419DB8F@socrates.local> <673F57D3-B2EC-4ABF-B450-EEEA3A4C185A@cs.utk.edu> <AANLkTinon97N3njcAV=FUj7-_ZJugazVCuaVbySbXr_L@mail.gmail.com> <193EC4D4-1B6C-4B14-ACD7-3237517566F5@cs.utk.edu> <21461_1284104520_o8A7fxBr026679_F51F0DFC-FC12-4F1A-A0E2-B5119FF446FA@dotat.at>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1925
Cc: Douglass Mike <douglm@rpi.edu>, Phillip Hallam-Baker <hallam@gmail.com>, Alexey Melnikov <Alexey.Melnikov@isode.com>, ietf-types@iana.org, Steven Lees <Steven.Lees@microsoft.com>, IETF@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2010 13:40:29 -0000

Hi Tony,

--On September 10, 2010 8:41:05 AM +0100 Tony Finch <dot@dotat.at> wrote:

>> If you have a beef with the iCalendar data model, feel free to try to
>> come up with a better one.
>
> Funny you should say that :-)
> http://fanf.livejournal.com/104586.html

That is a beef about timezones - one piece of iCalendar, but my no means 
all of it.

I disagree with your suggestion of using a location to represent a timezone 
- there are a number of reasons why that won't work - not least that many 
events often do not have a physical location associated with them.

That said work is going on to move to a "timezone by reference" rather than 
"timezone by value" model for iCalendar. There are many driving forces 
behind that, including several of the points you mention, plus the fact 
that often times the timezone definition included in iCalendar data is 
larger than (character-wise) then the actual event information, wasting 
bandwidth.

To that end several options are being proposed. We have already posted a 
draft for a generic timezone service 
(<https://datatracker.ietf.org/doc/draft-douglass-timezone-service/>) - a 
server that can be queried for timezone definitions based on standard IDs 
(Olson identifiers). This allows clients and servers to get timely updates 
to timezone information (rather than having to wait for the next OS 
upgrade). We are working on defining how "timezone by reference" will work 
with the CalDAV calendar access protocol (RFC4791). Since that uses HTTP, 
simple client/server negotiation options exist to facilitate that.

Note that the timezone service is not intended to just be used by iCalendar 
related tools - but we expect/hope that any device that needs to cache 
timezone definitions (e.g. unix zoneinfo data) can also make use of that.

Best place to continue this particular aspect of the discussion would be 
the ietf-calsify WG mailing list.

-- 
Cyrus Daboo