Re: Registration of media type application/calendar+xml

ned+ietf@mauve.mrochek.com Fri, 10 September 2010 04:53 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8B53A67A1 for <ietf@core3.amsl.com>; Thu, 9 Sep 2010 21:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Ouf9DtOtLC for <ietf@core3.amsl.com>; Thu, 9 Sep 2010 21:53:23 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 14E393A6837 for <IETF@IETF.ORG>; Thu, 9 Sep 2010 21:53:23 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NRP8H5I7G0004JC3@mauve.mrochek.com> for IETF@IETF.ORG; Thu, 9 Sep 2010 21:53:46 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NRM5YC121S003JZ5@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for IETF@IETF.ORG; Thu, 9 Sep 2010 21:53:38 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01NRP8H2AP2Y003JZ5@mauve.mrochek.com>
Date: Thu, 09 Sep 2010 20:38:49 -0700 (PDT)
Subject: Re: Registration of media type application/calendar+xml
In-reply-to: "Your message dated Thu, 09 Sep 2010 21:44:07 -0400" <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu>
To: Keith Moore <moore@cs.utk.edu>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1284093283; i=@mrochek.com; bh=0TbIu/GF1N32/Ag2X/NoY6o629LvSdVuPx32+nGPqww=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Zy4zfLftrmRyt5gmBH4TBUeM6uikXAvWCqp9w8S1ElWTqlXX/yvmX7Kxngi1eKDFg a/okErHp0VuUMl00O+LFcvv7nsxQefNW97Ed1jG17P0YW0kwGRSBvUFGtDcn1GezL6 lgbS8odZv5PhGuXaNGJSNVALiueIczUO044FttyY=
Cc: "Cyrus Daboo \(cyrus@daboo.name\)" <cyrus@daboo.name>, ietf-types@iana.org, Steven Lees <Steven.Lees@microsoft.com>, Douglass Mike <douglm@rpi.edu>, IETF@IETF.ORG
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2010 04:53:26 -0000

> 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.

In the case of Sieve, introducing the sort of skew you're worried about could
only be done by violating RFC 5228 on the regular format side (by changing the
core language syntax) or RFC 5784 on the XML side (by introducing an
incompatible schema change).

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.

> 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. (And out of the many Sieve extensions that have been
specified, exactly one introduced new controls, and additional extensions of
this sort are very unlikely.) Morever, had this one list been viewed as a
problem it could easily been eliminated, at the cost of making the XML
representation a little less clear. 

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.

> 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.

It should also be noted that in the case of XML, the existence of certain of
those tools also lessens the difficulty of implementing conversions from XML to
the original format. I know I sound like a broken record, but once again  RFC
5784 provides an example of this: It includes a stylesheet to convert from the
XML representation to the original format.

FWIW, I think including such a conversion stylesheet would be very useful.

> In summary, this is a thoroughly bad idea which can only do harm.

Again, I strongly disagree.

> Please withdraw this proposal, or at least withdraw the types application
> until the proposal has enjoyed more review.

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.

Now, on to the registration itself...

> > To: ietf-types@iana.org
> > Subject: Registration of media type application/calendar+xml
> > Type name: application
> > Subtype name: calendar+xml
> > Required parameters: none
> > Optional parameters:

> > charset, method, component and optinfo as defined for the text/calendar
> > media type

I have to question the inclusion of the charset parameter here. XML has its own
internal charset label, and having this parameter opens the door to charset
label silly states. Perhaps it would be better to map the text/calendar charset
parameter to the internal XML label, and vide versa.

> > Encoding considerations:

> > iCalendar data is typically UTF-8 and thus the XML representation will
> > follow that. As a result, for 7-bit transports, data in UTF-8 MUST be encoded
> > in quoted-printable or base64.

It is customary to include a value of 7bit, 8bit, or binary here and I believe
8bit is the correct value. While it is true that XML can use UTF-16 and similar
charsets that require a binary encoding label, this is a mapping of a text
type, which cannot employ UTF-16.

> > Security considerations:

> > This extension does not introduce any new security concerns than those
> > already described in iCalendar (RFC5545).

The use of XML actually raises a few additional security considerations that
should be mentioned. The text in section 5 of RFC 5784 covers these.

> > Interoperability considerations:
> > This media type provides an alternative syntax to iCalendar data based on XML.
> > Published specification:
> > This specification. (http://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-06.txt)
> > Applications which use this media type:
> > Applications that currently make use of the text/calendar media type can use this as an alternative.
> > Additional information:
> > Magic number(s): None
> > File extension(s): XML data should use "xml" as the file extension.

This is entirely your choice, but I'm not sure this recommendation is a great
idea.

> > Macintosh file type code(s): None specified.
> > Person & email address to contact for further information:  Steven Lees
> > EMail: steven.lees@microsoft.com

Although this is an individual submission, it's in the standards tree so you
might consider referring this to the calendar discussion list.

> > Intended usage:
> > COMMON
> > Restrictions on usage:
> > There are no restrictions on where this media type can be used.
> > Author:
> > Cyrus Daboo
> > EMail:  cyrus@daboo.name
> > Mike Douglass
> > EMail:  douglm@rpi.edu
> > Steven Lees
> > EMail:  steven.lees@microsoft.com
> > Change controller: IETF

				Ned