Registration of media type application/calendar+xml

[Keith Moore]

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.

Keith


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

> To:
> ietf-types at iana.org
> 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. (http://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-06.txt)
> 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: steven.lees at microsoft.com
> Intended usage:
> COMMON
> Restrictions on usage:
> There are no restrictions on where this media type can be used.
> Author:
> Cyrus Daboo
> EMail:  cyrus at daboo.name
> Mike Douglass
> EMail:  douglm at rpi.edu
> Steven Lees
> EMail:  steven.lees at microsoft.com
> Change controller:
> IETF
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/ietf-types/attachments/20100909/dbbb6ce0/attachment-0001.html>