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.
I strongly disagree.
Whenever you define an alternate representation of something, there will inevitably be skew between the original representation and the alternate representation.
This is demonstrably false. The Sieve in XML representation specified in RFC 5784 provides a counterexample - the way the format and mapping is defined, there's no way to represent anything in the XML variant that cannot be represent in the regular variant, and vice versa. In the case of Sieve, introducing the sort of skew you're worried about could only be done by violating RFC 5228 on the regular format side (by changing the core language syntax) or RFC 5784 on the XML side (by introducing an incompatible schema change). I have only done a cursory review of iCalendar in XML specification, but I believe it covers this issue adequately, and according to the document, it clearly intends to define a format that fully support round trips between the representations. If you believe it does not, it is up to you to provide specifics of how it does not, rather than asserting there's a problem without any actual evidence.
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.
Also demonstrably false, and once again RFC 5784 provides a counterexample. When Sieve extensions are defined the only thing that ever needs to be updated in the mapping to accomodate them is the list of controls, which is needed to map to the XML format. (And out of the many Sieve extensions that have been specified, exactly one introduced new controls, and additional extensions of this sort are very unlikely.) Morever, had this one list been viewed as a problem it could easily been eliminated, at the cost of making the XML representation a little less clear. Again, if you believe that introduction of new iCalendar properties will require updating the mapping to an unaceptable degree, it is up to you to cite specific exmaples instead of just asserting there's a problem.
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.
Yes, the existence of multiple formats can be an issue, but so can the inability to easily manipulate application data in popular environments using readily available tools. IMO the tradeoffs in this case are *overwhelmingly* on the side of being able to manipulate calendar data using XML tools. It should also be noted that in the case of XML, the existence of certain of those tools also lessens the difficulty of implementing conversions from XML to the original format. I know I sound like a broken record, but once again RFC 5784 provides an example of this: It includes a stylesheet to convert from the XML representation to the original format. FWIW, I think including such a conversion stylesheet would be very useful.
In summary, this is a thoroughly bad idea which can only do harm.
Again, I strongly disagree.
Please withdraw this proposal, or at least withdraw the types application until the proposal has enjoyed more review.
First of all, I'm actually kicking myself now that Sai and I didn't include a registration for application/sieve+xml in RFC 5784. If we ever do a revision I'll be sure to correct that omission. Second and far more important, the ietf-types list is for preliminary reviews only. In the case of a standards tree type like this that's being defined in an RFC, approval comes from the IESG, and that will happen as part of the review and approval process for the actual specification. It is therefore entirely appropriate for this registration to be posted to the list at this time so it can be reviewed. Now, on to the registration itself...
To: ietf-types@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
I have to question the inclusion of the charset parameter here. XML has its own internal charset label, and having this parameter opens the door to charset label silly states. Perhaps it would be better to map the text/calendar charset parameter to the internal XML label, and vide versa.
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.
It is customary to include a value of 7bit, 8bit, or binary here and I believe 8bit is the correct value. While it is true that XML can use UTF-16 and similar charsets that require a binary encoding label, this is a mapping of a text type, which cannot employ UTF-16.
Security considerations:
This extension does not introduce any new security concerns than those already described in iCalendar (RFC5545).
The use of XML actually raises a few additional security considerations that should be mentioned. The text in section 5 of RFC 5784 covers these.
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.
This is entirely your choice, but I'm not sure this recommendation is a great idea.
Macintosh file type code(s): None specified. Person & email address to contact for further information: Steven Lees EMail: steven.lees@microsoft.com
Although this is an individual submission, it's in the standards tree so you might consider referring this to the calendar discussion list.
Intended usage: COMMON Restrictions on usage: There are no restrictions on where this media type can be used. Author: Cyrus Daboo EMail: cyrus@daboo.name Mike Douglass EMail: douglm@rpi.edu Steven Lees EMail: steven.lees@microsoft.com Change controller: IETF
Ned