Re: Registration of media type application/calendar+xml

Cyrus Daboo <> Fri, 10 September 2010 14:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C5C03A67EB for <>; Fri, 10 Sep 2010 07:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.462
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZS8qP+wqFPnQ for <>; Fri, 10 Sep 2010 07:23:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 45F033A6403 for <IETF@IETF.ORG>; Fri, 10 Sep 2010 07:23:51 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E738F19240243; Fri, 10 Sep 2010 10:24:17 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xE0IoUhQNNud; Fri, 10 Sep 2010 10:24:13 -0400 (EDT)
Received: from (unknown []) by (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 <>
To: Keith Moore <>
Subject: Re: Registration of media type application/calendar+xml
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
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 <>,, Steven Lees <>, Douglass Mike <>, IETF@IETF.ORG
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 

>> 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