Re: Registration of media type application/calendar+xml

On 9/10/10 11:21 AM, Keith Moore 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.
Mumble. It's a lot harder to make a web browser do something useful with a calendar object (no matter what the syntax) than it is to make a web browser do something useful with contact information.
And I *like* JSON. I think it's a good approximation to what XML should have been.
It's not clear to me how your personal preference for JSON over XML is relevant to registration of the application/calendar+xml media type or continued work on draft-daboo-et-al-icalendar-in-xml. However, given that you seem to object to the XML representation of vCards, calendaring objects, and just about anything else, I suggest that you start a thread about XML vs. JSON on the apps-discuss list rather than filling up the archives of the ietf-types and ietf@ietf.org lists. https://www.ietf.org/mailman/listinfo/apps-discuss Peter -- Peter Saint-Andre https://stpeter.im/
participants (1)
-
Peter Saint-Andre