Re: Registration of media type application/calendar+xml
Cyrus Daboo <cyrus@daboo.name> Fri, 10 September 2010 02:22 UTC
Return-Path: <cyrus@daboo.name>
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 B503D3A6781 for <ietf@core3.amsl.com>; Thu, 9 Sep 2010 19:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.435
X-Spam-Level:
X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 k4p161Po9m0N for <ietf@core3.amsl.com>; Thu, 9 Sep 2010 19:22:06 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 011173A680A for <IETF@IETF.ORG>; Thu, 9 Sep 2010 19:22:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 4E7311922B064; Thu, 9 Sep 2010 22:22:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRhQyfiXBbfI; Thu, 9 Sep 2010 22:22:28 -0400 (EDT)
Received: from [17.101.35.28] (unknown [10.0.1.1]) by daboo.name (Postfix) with ESMTPSA id 9EC441922B052; Thu, 9 Sep 2010 22:22:28 -0400 (EDT)
Date: Thu, 09 Sep 2010 22:22:28 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Keith Moore <moore@cs.utk.edu>, Steven Lees <Steven.Lees@microsoft.com>
Subject: Re: Registration of media type application/calendar+xml
Message-ID: <B0EA09C87A5701A94419DB8F@socrates.local>
In-Reply-To: <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu>
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="3288"
Cc: Alexey Melnikov <Alexey.Melnikov@isode.com>, ietf-types@iana.org, 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 02:22:07 -0000
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@cs.utk.edu> 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
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… ned+ietf
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Tony Finch
- Re: Registration of media type application/calend… Julian Reschke
- Re: Registration of media type application/calend… Julian Reschke
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Julian Reschke
- Re: Registration of media type application/calend… ned+ietf
- Re: Registration of media type application/calend… Julian Reschke
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Cyrus Daboo
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Peter Saint-Andre
- Re: Registration of media type application/calend… ned+ietf
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Dave CROCKER
- Re: Registration of media type application/calend… Phillip Hallam-Baker
- Re: Registration of media type application/calend… Phillip Hallam-Baker
- Re: Registration of media type application/calend… Phillip Hallam-Baker
- Re: Registration of media type application/calend… Phillip Hallam-Baker
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Nathaniel Borenstein
- Re: Registration of media type application/calend… Keith Moore
- Re: Registration of media type application/calend… Phillip Hallam-Baker
- Re: Registration of media type application/calend… ned+ietf
- Re: Registration of media type application/calend… Keith Moore