Re: Registration of media type application/calendar+xml

Cyrus Daboo <cyrus@daboo.name> Fri, 10 September 2010 14:23 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 9C5C03A67EB for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 07:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.462
X-Spam-Level:
X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 ZS8qP+wqFPnQ for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 07:23:51 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 45F033A6403 for <IETF@IETF.ORG>; Fri, 10 Sep 2010 07:23:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E738F19240243; Fri, 10 Sep 2010 10:24:17 -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 xE0IoUhQNNud; Fri, 10 Sep 2010 10:24:13 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 4BA4519240237; Fri, 10 Sep 2010 10:24:12 -0400 (EDT)
Date: Fri, 10 Sep 2010 10:24:10 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Keith Moore <moore@cs.utk.edu>
Subject: Re: Registration of media type application/calendar+xml
Message-ID: <79B4EA2633639B353AF2C432@caldav.corp.apple.com>
In-Reply-To: <6669_1284127761_o8AE9KoR012176_3ADB01EC-68F9-4AEC-A260-7A3B5575A316@cs.utk.edu>
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu> <01NRP8H2AP2Y003JZ5@mauve.mrochek.com> <22026_1284097229_o8A5eRUG005394_D07F8B0F-3157-47BF-8F8E-38A7B4C7A34E@cs.utk.edu> <43F23935E7908D7304FE0482@caldav.corp.apple.com> <6669_1284127761_o8AE9KoR012176_3ADB01EC-68F9-4AEC-A260-7A3B5575A316@cs.utk.edu>
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=1912
Cc: Ned Freed <ned.freed@mrochek.com>, ietf-types@iana.org, Steven Lees <Steven.Lees@microsoft.com>, Douglass Mike <douglm@rpi.edu>, 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 14:23:52 -0000

Hi Keith,

--On September 10, 2010 10:09:11 AM -0400 Keith Moore <moore@cs.utk.edu> 
wrote:

>> That is precisely the goal of draft-daboo-et-al-icalendar-in-xml.
>> iCalendar components, properties, parameters and values all map to XML
>> in a consistent manner with no need to "special case" based on type or
>> value.
>
> But you're not doing that in the draft.  You explicitly list every
> keyword.  Every time a new component, property, parameter, etc is added
> to iCalendar, the mapping code will have to change also.  The trick is to
> be able to translate between formats, with no changes to the code needed
> even when the format is extended.

Fair enough. We can adjust e.g. Section 3.7 that talks about only X- 
extensions to also refer to any new iCalendar data objects. The basic 
premise being that new iCalendar data object names map directly to an XML 
element name. After each table in the previous sections we can add a 
reference to section 3.7 with a statement that that is how new items will 
be handled.

>> Conversion to/from XML is trivial - I have coded at least one half of
>> that and I know others who have done both ways.It should also be easy to
>> put together an XSLT to go from XML to iCalendar - with the only
>> possible difficulty being having to apply escaping and line folding as
>> required by iCalendar.
>
> That would be great, again provided you don't have to explicitly list
> every keyword.  It still wouldn't convince me that XML iCalendar is
> sufficiently valuable to be worth the degraded interoperability.  But if
> you're going to have two formats, being able to automatically convert
> between them is the best way to do that.

It has always been our intent to have a 1-to-1 mapping between the two. We 
in fact went out of our way to ensure that the XML schema would not 
restrict in anyway what could be done with new iCalendar data objects.

-- 
Cyrus Daboo