ietf
[Top] [All Lists]

Re: Registration of media type application/calendar+xml

2010-09-10 12:22:29

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. 

And I can even see that having a DOM-based representation of calendar data for 
internal use in a program, as awkward as that is, might be better than lots of 
ad hoc internal representations.   (I can't quite put my finger on it, but 
there does seem to be something about iCalendar that encourages building poor 
internal representations of the data.)

Still, if I were designing a PIM that wanted to be able to have web browsers 
manipulate contact information, I'd use vCard as the interchange format and use 
JSON only for the purpose of communicating with Javascript code in the browser.

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.

Code reuse is all the rage these days.  Can't they leverage work that someone 
else has already done?  

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.

As much as I'd like to believe you can separate the model from the syntax, 
experience seems to indicate otherwise.  Every time I've seen people borrow a 
data model from one protocol and move it to another, the data models used by 
the two protocols have diverged.    Think about the differences between 
interpretation of email header fields and HTTP header fields.  The field names 
get borrowed, the syntax of each field generally stays the same, but the 
semantics change. 

And there are reasons why the semantics change.  In the case of calendar data, 
consider timezone handling.  If you're sending out an event "in the blind" (say 
over email) without knowing whether the recipient will recognize your event 
timezone, you want to send as much mapping data as the receiver will need - 
even though it might change.  But if you're sending the event over some link 
that permits interaction and negotiation, you probably want to either ask the 
receiver whether it supports the timezone, or give it a link to the timezone 
data so that it can refresh it as needed.

This also reminds me of why IETF avoids standardizing APIs: it's because people 
tried to use the API (which is pretty much just a data model) as the basis for 
interoperability rather than bits on the wire.  And it didn't work.

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).

Something like that would help, I think.  It seems like the appropriate goal is 
to give clear guidance to implementors about when to use iCalendar and when to 
use the other formats.  I think there's a case to be made for standardizing on 
a single format for (a) sending "in the blind" when you can't do 
content-negotiation, and (b) as a "must support" format (even if you can 
negotiate others, you must support the base format, so that every 
implementation has a basis for interoperation).    And I suspect that iCalendar 
has the advantage as the "must support" format; though somebody might like to 
argue the opposite case.


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 :-)

perhaps.

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf