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@xxxxxxxxxx>
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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf