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(_dot_)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(_dot_)lees(_at_)microsoft(_dot_)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(_dot_)name
Mike Douglass
EMail: douglm(_at_)rpi(_dot_)edu
Steven Lees
EMail: steven(_dot_)lees(_at_)microsoft(_dot_)com
Change controller:
IETF
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf