Registration of media type application/calendar+xml

[Cyrus Daboo]

Hi Keith,
(cc'ing Apps area ADs - I believe Peter intends to "sponsor" this draft so 
he at least should be aware of our discussion here)

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

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

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.

> Whenever you define an alternate representation of something, there will
> inevitably be skew between the original representation and the alternate
> representation.

iCalendar is itself extensible in terms of the addition of new properties 
and parameters. The trivial mapping of the iCalendar object model to our 
XML schema allows such extensions to be trivially mapped.

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

If iCalendar is extended in such a way that it is no longer compatible with 
the XML mapping, then it would really be a completely new version that 
would itself not be compatible with the existing iCalendar v2.0. If that 
happens, well compatibility has clearly been thrown out the window.

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

Correct - having two representations can cause problems like this. However, 
with the advent of HTTP-based calendar protocols, the content negotiation 
mechanisms in HTTP (e.g. Accept header) can be used to push most of the 
burden for this on servers rather than clients.

> Please withdraw this proposal, or at least withdraw the types application
> until the proposal has enjoyed more review.

Having a MIME type for this representation is critical to enabling content 
negotiation features. I feel strongly that this is a valid and useful 
proposal and we are already seeing uptake in the form of smart grid work 
and others.

Whilst this is an individual submission, I would point you to 
<https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/> which is 
the product of the vCardDAV working group. That specification defines a 
mapping of vCard to XML which follows the same basic design of our 
iCalendar-in-XML work.


-- 
Cyrus Daboo