Registration of media type application/calendar+xml

[Keith Moore]

On Sep 9, 2010, at 11:38 PM, Ned Freed 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.
> 
> I strongly disagree.
> 
>> Whenever you define an alternate representation of something, there will
>> inevitably be skew between the original representation and the alternate
>> representation.
> 
> This is demonstrably false. The Sieve in XML representation specified in RFC
> 5784 provides a counterexample - the way the format and mapping is defined,
> there's no way to represent anything in the XML variant that cannot be
> represent in the regular variant, and vice versa.

RFC 5784 might well be a valiant effort toward that.  But it has only been out a few months, so I think the jury is still out as to how well it works in practice.

I also think it helps that RFC 5784 specifically says it's not intended as an alternate storage format for Sieve.  I can certainly see some utility in being able to use XML tools to manipulate things not originally written in XML.

But here's the acid test.  If you can define a mapping from iCalendar to XML that doesn't require any string constants to describe it (other than for iCalendar keywords that imply nesting, and separators that are used in a regular fashion in iCalendar), and if you can define the inverse mapping from XML to iCalendar without naming more than a couple of specific element or parameter names - then I'll concede that the mapping will probably continue to work in the face of extensions to the iCalendar data model.   Otherwise, I'm highly dubious. 

Even then, this would not address the degraded interoperability resulting from the need to have multiple formats.

> I have only done a cursory review of iCalendar in XML specification, but I
> believe it covers this issue adequately, and according to the document, it
> clearly intends to define a format that fully support round trips between the
> representations. If you believe it does not, it is up to you to provide
> specifics of how it does not, rather than asserting there's a problem without
> any actual evidence.

I disagree, because there are interoperability problems resulting from the introduction of an alternate format even if the mappings remain invertable in the presence of 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.
> 
> Also demonstrably false, and once again RFC 5784 provides a counterexample.
> When Sieve extensions are defined the only thing that ever needs to be updated
> in the mapping to accomodate them is the list of controls, which is needed to
> map to the XML format.

I think you've just illustrated my point.

Though really I'm not as worried about Sieve as I doubt that there's nearly as much deployment of Sieve as there is of iCalendar.    I think it's far more likely that all Sieve implementations can be upgraded to support XML, if there's a desire to do that, than that all iCalendar implementations can be upgraded to support XML.  

I also think that Sieve<>XML is inherently saner than iCalendar<>XML because Sieve (being essentially a programming language) is already structured similarly to the way XML is structured.

> Again, if you believe that introduction of new iCalendar properties will
> require updating the mapping to an unaceptable degree, it is up to you to cite
> specific exmaples instead of just asserting there's a problem.


I think that the burden is on the proposers to justify producing an incompatible alternative to a existing standard, which will definitely harm interoperability.

> 
>> 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.
> 
> Yes, the existence of multiple formats can be an issue, but so can the
> inability to easily manipulate application data in popular environments using
> readily available tools. IMO the tradeoffs in this case are *overwhelmingly* on
> the side of being able to manipulate calendar data using XML tools.

If people want to define mappings between iCalendar and XML just for the sake of being able to manipulate the data using XML tools, that doesn't bother me so much.   It's when people want to start exchanging calendar data using XML in some cases and iCalendar in others that the interoperability problems start cropping up.  (Though I have to wonder how much it really helps to be able to manipulate calendar data using XML tools, as calendar manipulations tend to be fairly specialized to calendar applications.)

> First of all, I'm actually kicking myself now that Sai and I didn't include a
> registration for application/sieve+xml in RFC 5784. If we ever do a revision
> I'll be sure to correct that omission.

> Second and far more important, the ietf-types list is for preliminary reviews
> only. In the case of a standards tree type like this that's being defined in an
> RFC, approval comes from the IESG, and that will happen as part of the review
> and approval process for the actual specification. It is therefore entirely
> appropriate for this registration to be posted to the list at this time so it
> can be reviewed.

Yeah, I know...that's why I cc'ed the IETF list.   I am not arguing that the type registration itself is improper; I'm arguing that defining a new representation of iCalendar is a bad idea and should be discouraged by the IETF community.  And for that reason I'm asking the document authors to put the type registration on hold.

Keith