Re: Registration of media type application/calendar+xml Mon, 13 September 2010 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 313DA3A67E5 for <>; Mon, 13 Sep 2010 14:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.064
X-Spam-Status: No, score=-0.064 tagged_above=-999 required=5 tests=[AWL=-1.657, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_83=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fj0aDfD8SBcr for <>; Mon, 13 Sep 2010 14:13:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39A663A6781 for <IETF@IETF.ORG>; Mon, 13 Sep 2010 14:13:11 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for IETF@IETF.ORG; Mon, 13 Sep 2010 14:13:32 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> (original mail from for IETF@IETF.ORG; Mon, 13 Sep 2010 14:13:28 -0700 (PDT)
Message-id: <>
Date: Sun, 12 Sep 2010 20:10:12 -0700 (PDT)
Subject: Re: Registration of media type application/calendar+xml
In-reply-to: "Your message dated Sat, 11 Sep 2010 00:56:03 -0400" <>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <> <> <> <> <>
To: Keith Moore <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mauve; t=1284411111;; bh=37jb8yHABn2dYIzoRxh83weB5tdaoSXypyflgJgD6gg=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=lHQ4jxHJM74pZ1qEKOAIbI0D/UNBK1nieTYmjPnh+pUUQFNL6ke5s2DQc1rdIn3qm Wy/2EyGoTtCKLHcAD9VKzywgzC1nPAbk/bx3wbEBy75Su+tDNL8dq2VE2ijxH4d+I4 0F0X3+yX2jJc2j+40WkaDv8a+FcJDSB7KIBglNmk=
Cc: "" <IETF@IETF.ORG>, Steven Lees <>,, Douglass Mike <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Sep 2010 21:13:13 -0000

> [ietf-types removed to spare those who just want to read type applications.]

> > We need to distinguish between alternate syntactic forms, versus alternate
> > semantic environments.  Translating between versions of the former do not need
> > to lose information.  Translating between versions of the latter almost
> > certainly do.  Losing information is about differences in semantics.

> I'm not convinced that there is a difference in practice between the two. 
> Different syntactic forms tend to get used in different environments, and to
> adapt to the requirements/conventions of those environments.

That has not been my experience. My experience has been that when it comes to
interoperability in both the short and long term, clear, accurate and concise
specifications of the formats and the mappings between them are key.

> calendar+xml is intended to be merely a syntactic alternative.  I just don't
> believe it is likely to stay that way.

And I believe it will if it is done properly, which in the absence of any
actual evidence is an equally valid statement. Again, the problem with this
entire discussion is that it's mostly happening at the 20,000 foot level,
leaving the details of the protocol - which really matter - behind.

> > As I understand the calendar+xml, it is "merely" a syntactic alternative. 
> > To the extent that it requires information loss when being re-encoded, yes
> > that should be fixed.  But it's not likely to be difficult and the
> > existence of two syntactic forms is not inherently problematic.  (We have
> > lots of examples on the net of doing this quite nicely, at different
> > layers of Internet architecture.)

> please cite specific examples.  it might be instructive to see why they work
> or don't work well.

Fair enugh, but there are vast numbers of examples of alternate syntactic forms
out there - so many that I'm sure you can find an example to support almost any
assertion you want to make.

So let's narrow things down to formally standardized data formats where
semantic differences were disallowed. I've already discussed Sieve as an
example in this context, but another, older one would be CGM (computer graphics

This is actually an instructive case between there were three syntaxes for CGM,
not two: text, binary, and compressed text. (More recently, something called
WebCGM has been specified, but this happened long after my involvement ceased
and I know nothing about it.) Both the text and binary formats were quite
straightforward and clearly specified. Back in the day we had multiple
applications that happily generated either the text or binary format, and at
least one which could generate both. Applications able to process CGM generally
only supported one variant, but there were at least two readily available
software packages that could convert between text and binary. 

But what about the compressed text format? It turned out to be quite
problematic. Part of the problem was obvious: Three formats is pretty clearly
at least one too many. It's enough of a pain to support two formats; three was
seen by implementers as ... excessive. Even worse, the compressed text format
was much more complex, and IMO not terribly well specified. Usage of it was
comparitively rare, and the software that did try and handle it tended to have
gotten minimal testing and was quite buggy. As I recall, we had one application
that only supported compressed text output, and we had a devil of a time
finding something that could process it without crashing. Even worse, things
would work fine until something new was tried, and then more problems would

So what are the lessons here? Well, pretty much the same old same old: Format
simplicity and specification clarity are the key to successful
interoperability, far more so than having a single format. In the case of CGM,
converting wasn't the problem, use of the compressed text format in any context
was. Things would almot certainly have been worse had compressed text been the
only format available.

> the best one that immediately comes to mind is raw IP vs. PPP with header
> compression.  I think it works because the latter representation is only used
> on the wire between two endpoints of a network link.  And if it fails to
> faithfully reproduce the packet, it's very clear where the problem is. 
> (there's no argument about which representation is correct - the original
> packet is always correct.).

I don't think the comparison is particularly useful because the domains are so
different, but even so, I think the fact that the mapping is fairly simple and
clearly specified goes a long way to making these protocols interoperate as
well as they do.