On Sep 9, 2010, at 10:22 PM, Cyrus Daboo wrote:

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

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?

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

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

But your document doesn't define what the mapping is.  And your mapping spec (not to mention implementations) will always lag extensions.

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

Sure, but if that should actually be needed, why do you want to make it even more difficult?    If and when there were a need for an iCalendar 3.0 - i.e. an incompatible change because there was no way to shoehorn the new features into the old format - it might make sense to define _that_ to use XML.

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

Provided, of course, that HTTP-based calendar protocols are being used.   But currently, all of the iCalendar content I receive is over email.

Even if you have content-negotiation, having two formats still means there are two code paths, which introduces additional opportunities for failure.

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

Let me be clear.  I'm not saying just withdraw the MIME type application.  I'm asking you to abandon the internet-draft also.  Don't introduce an incompatible iCalendar format.  Then you don't need content-negotiation for calendar data.

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

I don't doubt at all that there are people jumping on the bandwagon.  That's not a sound justification for degrading interoperability of calendar products.

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

One example of bad practice does not justify another.  That is what is known as propagation of error.

Keith