Re: Registration of media type application/calendar+xml

Keith Moore <moore@cs.utk.edu> Fri, 10 September 2010 14:08 UTC

Return-Path: <moore@cs.utk.edu>
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 E25ED3A6835 for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 07:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.423
X-Spam-Level:
X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 HUnGy6gVJhrn for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 07:08:50 -0700 (PDT)
Received: from ba.eecs.utk.edu (ba.eecs.utk.edu [160.36.56.154]) by core3.amsl.com (Postfix) with ESMTP id 87BC33A6403 for <IETF@IETF.ORG>; Fri, 10 Sep 2010 07:08:50 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by ba.eecs.utk.edu (Postfix) with ESMTP id 3E6AA1400BF; Fri, 10 Sep 2010 10:09:17 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at eecs.utk.edu
Received: from ba.eecs.utk.edu ([127.0.0.1]) by localhost (ba.eecs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDoRClIVxGnf; Fri, 10 Sep 2010 10:09:16 -0400 (EDT)
Received: from 173-137-249-197.pools.spcsdns.net (173-137-249-197.pools.spcsdns.net [173.137.249.197]) by ba.eecs.utk.edu (Postfix) with ESMTP id AC0471400BD; Fri, 10 Sep 2010 10:09:14 -0400 (EDT)
Subject: Re: Registration of media type application/calendar+xml
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@cs.utk.edu>
In-Reply-To: <43F23935E7908D7304FE0482@caldav.corp.apple.com>
Date: Fri, 10 Sep 2010 10:09:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1081)
Cc: Steven Lees <Steven.Lees@microsoft.com>, ietf-types@iana.org, Ned Freed <ned.freed@mrochek.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:08:52 -0000

On Sep 10, 2010, at 9:56 AM, Cyrus Daboo wrote:

> Hi Keith,
> 
> --On September 10, 2010 1:40:16 AM -0400 Keith Moore <moore@cs.utk.edu> wrote:
> 
>> But here's the acid test.  If you can define a mapping from iCalendar to
>> XML that doesn't require any string constants to describe it (other than
>> for iCalendar keywords that imply nesting, and separators that are used
>> in a regular fashion in iCalendar), and if you can define the inverse
>> mapping from XML to iCalendar without naming more than a couple of
>> specific element or parameter names - then I'll concede that the mapping
>> will probably continue to work in the face of extensions to the iCalendar
>> data model.   Otherwise, I'm highly dubious.
> 
> 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.

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

Keith