Re: Registration of media type application/calendar+xml

Keith Moore <> Fri, 10 September 2010 01:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E76EC3A6879 for <>; Thu, 9 Sep 2010 18:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BxudrLtc93Pj for <>; Thu, 9 Sep 2010 18:43:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A878A3A686E for <IETF@IETF.ORG>; Thu, 9 Sep 2010 18:43:49 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 7CCD21009E; Thu, 9 Sep 2010 21:44:16 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oNzol6hEwFzj; Thu, 9 Sep 2010 21:44:15 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id C93F010098; Thu, 9 Sep 2010 21:44:10 -0400 (EDT)
Subject: Re: Registration of media type application/calendar+xml
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-12-833169327
From: Keith Moore <>
In-Reply-To: <>
Date: Thu, 9 Sep 2010 21:44:07 -0400
Message-Id: <>
References: <>
To: Steven Lees <>
X-Mailer: Apple Mail (2.1081)
Cc: "Cyrus Daboo \(\)" <>,, 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 01:43:52 -0000

This was a bad idea when it was first proposed (if I recall correctly) around ten years ago, and it's still a bad idea.

Whenever you define an alternate representation of something, there will inevitably be skew between the original representation and the alternate representation.

This remains true even if you define mapping rules between the two (as you do in this document).   The problem with mapping rules, which I believe I pointed out around ten years ago, is that the rules are specific to a particular version of iCalendar.  If either iCalendar is extended, or the XML representation is extended, there's no guidance as to how to map the extended format into the other representation.

In addition, defining a new calendar format harms interoperability even if you can keep the two representations in sync.  The reason is that it's no longer sufficient for a calendar application to support just one representation of calendar data.  In order to reliably interoperate, it must at least able to read both, and it probably needs to be able to write both.  That, and when sending calendar data to other applications, either both representations must be sent, or some way of negotiating which format to use is needed, or the user must be asked to choose which format to export.

In summary, this is a thoroughly bad idea which can only do harm.

Please withdraw this proposal, or at least withdraw the types application until the proposal has enjoyed more review.


On Sep 2, 2010, at 6:44 PM, Steven Lees wrote:

> To:
> Subject:
> Registration of media type application/calendar+xml
> Type name:
> application
> Subtype name:
> calendar+xml
> Required parameters:
> none
> Optional parameters:
> charset, method, component and optinfo as defined for the text/calendar media type
> Encoding considerations:
> iCalendar data is typically UTF-8 and thus the XML representation will follow that. As a result, for 7-bit transports, data in UTF-8 MUST be encoded in quoted-printable or base64.
> Security considerations:
> This extension does not introduce any new security concerns than those already described in iCalendar (RFC5545).
> Interoperability considerations:
> This media type provides an alternative syntax to iCalendar data based on XML.
> Published specification:
> This specification. (
> Applications which use this media type:
> Applications that currently make use of the text/calendar media type can use this as an alternative.
> Additional information:
> Magic number(s): None
> File extension(s): XML data should use "xml" as the file extension.
> Macintosh file type code(s): None specified.
> Person & email address to contact for further information:
> Steven Lees
> EMail:
> Intended usage:
> Restrictions on usage:
> There are no restrictions on where this media type can be used.
> Author:
> Cyrus Daboo
> EMail:
> Mike Douglass
> EMail:
> Steven Lees
> EMail:
> Change controller: