Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Keith,

--On September 9, 2010 10:51:10 PM -0400 Keith Moore <moore at cs.utk.edu> 
wrote:

>> An XML representation for iCalendar is vital if we are to keep iCalendar
>> relevant in the web-based world. The drive for this work comes from a
>> number of areas - in particular the smart grid effort sponsored by NIST
>> will make use of this as part of the standards suite they are defining.
>
> Somebody needs to talk some sense into those people.  Defining another
> calendar format will only harm interoperability.  It doesn't save any
> calendar implementation from needing to implement another parser, because
> if it wants to interoperate with existing products or be able to read old
> events it's still going to have to support iCalendar and probably
> vCalendar also.  So what's the _technical_ (not political) benefit from
> doing this?

First of all look at the mess we have got into with contacts (see recent 
discussion on the vcarddav WG mailing list). There we now have vCard, PoCo, 
OpenSocial and some new thing the OMA is doing (and their are lots of 
private apis too). Yet vCard has been around for a long time - why didn't 
those other folks just use that or at least propose fixes or extension to 
vcard that would satisfy their issues? Well, certainly in the case of PoCo 
one clear requirement was for a simple web/browser based solution - so they 
designed JSON and XML representations.

The same mess could happen to iCalendar too. In fact there are already lots 
of examples of "private" apis using XML to represent calendar data, see 
e.g. Google GDATA. Plus I know of some public event services that uses 
their own custom XML format for event publishers to submit calendar data to 
them. In fact the initial impetus for this work did come from one such 
public events company that really wanted to use iCalendar rather than some 
home grown solution, but really wanted that as XML. Sure you can argue that 
they should be made to parse iCalendar format, but why should they have to 
write their own new parser when they already have reliable, efficient XML 
processing available.

Frankly the important thing here is the semantics of the iCalendar model, 
not the syntax. I want developers to only have to concentrate on getting 
the semantics right without worry too much about the syntax.

Now I can understand your concern about poor interoperability when it comes 
to having the two data formats. I think for the HTTP-based world (CalDAV, 
iSchedule, web-services) this is really not a big deal given the content 
negotiation options. For something like iMIP (iCalendar in email) it is a 
much bigger problem. Speaking for myself only, and not my co-authors, I 
think I would be OK with adding a statement that iMIP messages SHOULD NOT 
use the application/calendar+xml format, or at the very least require both 
text/calendar and application/calendar+xml in e.g. a multipart/alternative 
(though I would worry that the later would cause existing clients problems, 
and lead to message bloat).

> IETF's job is to provide technical leadership, not to follow bad advice.
> Instead of caving into them, what we need to do is publish a draft called
> "Translating Everything into XML Considered Harmful".

Ah, yes. I seem to recall something similar for the use of HTTP - perhaps 
the author of RFC 3205 would like to author this new document too :-)


-- 
Cyrus Daboo