Re: Registration of media type application/calendar+xml

Keith Moore <moore@network-heretics.com> Tue, 14 September 2010 04:22 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 F15C83A6881 for <ietf@core3.amsl.com>; Mon, 13 Sep 2010 21:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FLGqx+nX81cL for <ietf@core3.amsl.com>; Mon, 13 Sep 2010 21:22:23 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id A24593A6868 for <IETF@IETF.ORG>; Mon, 13 Sep 2010 21:22:23 -0700 (PDT)
Received: from 108-108-15-138.pools.spcsdns.net (108-108-15-138.pools.spcsdns.net [108.108.15.138] (may be forged)) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id CEF64980 (AUTH admin@network-heretics.com); Mon, 13 Sep 2010 21:22:26 -0700
X-Mirapoint-Received-SPF: 108.108.15.138 108-108-15-138.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.15.138 108-108-15-138.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.15.138 108-108-15-138.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.15.138 108-108-15-138.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.15.138 108-108-15-138.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 108.108.15.138 108-108-15-138.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: <01NRUDJXYRTO000CVX@mauve.mrochek.com>
Date: Tue, 14 Sep 2010 00:22:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AA5A327-9F94-4343-B938-C7B3FD756A45@network-heretics.com>
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu> <01NRP8H2AP2Y003JZ5@mauve.mrochek.com> <4C8A7AB2.5090500@dcrocker.net> <6D1B9008-8C93-4DFA-98AB-75BBE642964D@network-heretics.com> <01NRUDJXYRTO000CVX@mauve.mrochek.com>
To: Ned Freed <ned.freed@mrochek.com>
X-Mailer: Apple Mail (2.1081)
Cc: "IETF@ietf.org" <IETF@IETF.ORG>, Steven Lees <Steven.Lees@microsoft.com>, dcrocker@bbiw.net, 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: Tue, 14 Sep 2010 04:22:25 -0000

Let me say off the bat that I'm now convinced that there is at least some marginal utility in having an XML representation of iCalendar.   And the barrier for registration of new types is deliberately low, so I now think there's enough utility in having such a type.

I still think it would be helpful to improve the mapping so that it's clear that it will work across reasonable changes/extensions to iCalendar format, and to simplify it so that it's easier to understand and implement.  

I also think it would be appropriate for the document to make it clear that the standard for exchange of calendar data between systems is still iCalendar format, and that implementations should still have the ability to import and export iCalendar.

>>> We need to distinguish between alternate syntactic forms, versus alternate
>>> semantic environments.  Translating between versions of the former do not need
>>> to lose information.  Translating between versions of the latter almost
>>> certainly do.  Losing information is about differences in semantics.
> 
>> I'm not convinced that there is a difference in practice between the two. 
>> Different syntactic forms tend to get used in different environments, and to
>> adapt to the requirements/conventions of those environments.
> 
> That has not been my experience. My experience has been that when it comes to
> interoperability in both the short and long term, clear, accurate and concise
> specifications of the formats and the mappings between them are key.

I certainly agree that if you're going to have multiple file formats, those are the optimal conditions.  If the mapping is simple enough, and the specification clear and concise enough that it's obvious how to write correct code to map between the two, the chance that implementations will support both formats is very good.

And without quoting and responding at length, I think your example of CGM is instructive.

Though I do have to wonder, if the mapping is really that simple, clear, and concise - why is there a need for any implementation to support multiple external formats?  Each system that prefers a tree-structured internal representation can just use that specification to convert at the boundary.

Anyway, I feel like I've made my point and it has been given due consideration, and I hope that the discussion has been useful for the authors and/or IESG.

Keith