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(_at_)cs(_dot_)utk(_dot_)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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf