Re: Registration of media type application/calendar+xml

Keith Moore <moore@network-heretics.com> Fri, 10 September 2010 16:44 UTC

Return-Path: <moore@network-heretics.com>
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 DA86F3A68EB for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 09:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599]
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 CjaAmn2GFcPo for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 09:44:39 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 3B4103A69CA for <IETF@IETF.ORG>; Fri, 10 Sep 2010 09:44:19 -0700 (PDT)
Received: from 173-137-249-197.pools.spcsdns.net (173-137-249-197.pools.spcsdns.net [173.137.249.197]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id CDZ20727 (AUTH admin@network-heretics.com); Fri, 10 Sep 2010 09:43:54 -0700
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
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@network-heretics.com>
In-Reply-To: <79B4EA2633639B353AF2C432@caldav.corp.apple.com>
Date: Fri, 10 Sep 2010 12:43:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D3B06F9-6B9D-476C-9E13-45F509511655@network-heretics.com>
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> <79B4EA2633639B353AF2C432@caldav.corp.apple.com>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1081)
Cc: Ned Freed <ned.freed@mrochek.com>, IETF@IETF.ORG, Keith Moore <moore@cs.utk.edu>, ietf-types@iana.org, Steven Lees <Steven.Lees@microsoft.com>, Douglass Mike <douglm@rpi.edu>
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 16:44:41 -0000

On Sep 10, 2010, at 10:24 AM, Cyrus Daboo wrote:

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

That would help.  But why do you need specific rules for any of the iCalendar data object names?  I can understand one or two exceptional cases, but if the mapping you have is truly adaptable, it shouldn't need many of those rules.

Keith