Re: Registration of media type application/calendar+xml

[Keith Moore <moore@xxxxxxxxxx>]

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@xxxxxxxx

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@xxxxxxxxxxxxx

Intended usage:

COMMON

Restrictions on usage:

There are no restrictions on where this media type can be used.

Author:

Cyrus Daboo

EMail:  cyrus@xxxxxxxxxx

Mike Douglass

EMail:  douglm@xxxxxxx

Steven Lees

EMail:  steven.lees@xxxxxxxxxxxxx

Change controller:

IETF

 

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf