Re: Registration of media type application/calendar+xml

Julian Reschke <> Fri, 10 September 2010 10:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00CEC3A6359 for <>; Fri, 10 Sep 2010 03:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.615
X-Spam-Status: No, score=-104.615 tagged_above=-999 required=5 tests=[AWL=-2.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q5MpgXyReZYR for <>; Fri, 10 Sep 2010 03:11:24 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D7DFC3A6A39 for <>; Fri, 10 Sep 2010 03:11:12 -0700 (PDT)
Received: (qmail invoked by alias); 10 Sep 2010 10:11:38 -0000
Received: from (EHLO []) [] by (mp068) with SMTP; 10 Sep 2010 12:11:38 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+9KzA7gVO9P8jLUQZyPUjCnzjcj5OE87SjD+stWm sWClzUzqrTTA2j
Message-ID: <>
Date: Fri, 10 Sep 2010 12:11:27 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3
MIME-Version: 1.0
To: Keith Moore <>
Subject: Re: Registration of media type application/calendar+xml
References: <> <> <B0EA09C87A5701A94419DB8F@socrates.local> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Douglass Mike <>, Phillip Hallam-Baker <>, Cyrus Daboo <>, Alexey Melnikov <>,, Steven Lees <>,
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: Fri, 10 Sep 2010 10:11:36 -0000

On 10.09.2010 07:09, Keith Moore wrote:
> On Sep 10, 2010, at 12:34 AM, Phillip Hallam-Baker wrote:
> ...
>> If you want to have a system in which 95% of your data structures are
>> in XML you probably don't want to have to introduce a separate syntax
>> and you most certainly do not want to deal with a separate data model
>> for dealing with calendaring.
> It's not at all clear that trying to coerce 95% of the data models in
> your system to be compatible with XML is a worthwhile goal. The XML data
> model is tortured. Trying to impose it on network protocols should be
> regarded as an act of violence.
> ...

That's *far* from clear. Could you elaborate in the context of 
calendaring? As far as I can tell, the torture is more about having to 
parse what we have today.

> At any rate, this proposal doesn't change the iCalendar data model - it
> just makes it harder to use. If you have a beef with the iCalendar data
> model, feel free to try to come up with a better one.

I disagree that it makes it harder to use, *unless* somebody wants to 
require support for this alternate format.

On the other hand, having an agreed-upon mapping from/to XML will make 
it easier for many developers. Well, at least those who don't have a 
problem with XML :-)

>> The iCalendar format represents a 1990s style approach to the problem.
>> There is no real separation of syntax from the data model. Software
>> developed in that manner is notoriously difficult to get right for the
>> reasons that Keith describes.
> XML has lots of problems of its own. I recently had to review a
> specification that referenced WS-i and WS-security and about a couple of
> thousand other pages of useless crap that went with it. All for the sake
> of being able to transmit about six meaningful name-value pairs from a
> client to a server. It was completely ridiculous.

Yes, WS-* sucks. Big news.

> I'm no fan of the iCalendar format, nor the vCard and vCalendar formats
> that preceded it. But for all of its purported generality (and perhaps
> because of it) XML has turned out to be no better, and in many ways
> worse. It's amazing how hard people will work to make a simple idea
> complex, especially when the simple idea has become a bandwagon, or (in
> this case) a religion.
> In principle, it would make sense for things to have a uniform syntax.
> But XML gets this wrong in several different ways. The most obvious is
> that XML data structures don't map well onto data structures supported
> by programming languages. That's probably because SGML wasn't designed
> to do that - it was designed to mark up text. Another problem is that
> XML confuses typing and naming. Another problem (especially when mapping
> other structures to/from XML) is that the distinction between parameters
> and sub-elements is pretty much arbitrary.

That may all be true. But strangely enough, there doesn't seem to be 
much energy to come up with something better *and* get people to agree 
on that.

Turning a type registration request into an to-XML-or-not-to thread 
doesn't appear to be productive to me.

>> XML is a substantial overhead if you are dealing with a single
>> protocol but when you are dealing with multiple protocols the benefits
>> are substantial and allow something like 70% of your coding effort to
>> be pushed onto the platform layer. That means that you have 70% less
>> new code and new code paths to contend with.
> If your programmer is spending 70% of his coding time dealing with a
> presentation layer, even one as convoluted as iCalendar, you should fire
> him. It's not like regular expression parsers are hard to come by these
> days. Nor are libraries that can parse standard formats hard to come by.

Can iCalendar be parsed reliably with regexps? (just asking).

> Another of the big problems with the XML religion is that its adherents
> have the mistaken impression that defining the syntax is most of the
> work of defining a protocol - so that once you decide to use XML, most
> of the work is done. Apparently, semantics don't matter much.

Another big problem with the anti-XML religion is that its adherents 
like to over-generalize, such as deducing badness of XML from 
WS-deathstar encounters.

Yes, there's lots of bad use of XML. The same can be said about other 
formats as well.

> ...
> It enforces consistency in syntax. Taken by itself, that's a good thing.
> But when you parse XML you don't get a very usable data structure. You
> get a mess. And once you do the work of transforming that data structure
> into an effective internal representation, you've negated whatever
> advantage you might have found in not having to have written a
> parser/generator for it. You haven't solved the problem of needing a
> parser and generator - you've just moved it. Instead of parsing text
> you're parsing a DOM structure. You've added an extra layer or two for
> no benefit.

The benefit is that the XML parser already has taken care of many things 
people get wrong all the time; character encodings, escaping, line 
endings etc.

> You're essentially arguing the syntax by which data is represented on
> the wire - the presentation layer - should constrain how data is
> represented internally in a system. And then you're arguing that the
> particular constraints imposed by XML are appropriate constraints.
> That's brain damage.

I don't think anybody argued that.

>> Now I would quite prefer to take about 50% or more of the XML spec and
>> discard it. They did a good job of taking out the most insane features
>> of SGML but there is much more cruft that could be cut out. But that
>> does not change the fact that using XML as is produces clearer
>> specifications that are more likely to be implemented without errors
>> than with the 1990s approach.
> As is often the case, you're simply and utterly incorrect.

OK, enough :-)

Can we please switch to a discussion of the RFC publication format now?

Best regards, Julian