Re: Registration of media type application/calendar+xml

Keith Moore <moore@network-heretics.com> Sat, 11 September 2010 04:55 UTC

Return-Path: <moore@network-heretics.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 00E183A687D for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 21:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.099, 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 L-mvGPlHPqvk for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 21:55:49 -0700 (PDT)
Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id DAE683A6881 for <IETF@IETF.ORG>; Fri, 10 Sep 2010 21:55:49 -0700 (PDT)
Received: from 173-137-249-197.pools.spcsdns.net (173-137-249-197.pools.spcsdns.net [173.137.249.197]) by m1.imap-partners.net (MOS 4.1.8-GA) with ESMTP id CEA38352 (AUTH admin@network-heretics.com); Fri, 10 Sep 2010 21:56:03 -0700
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
X-Mirapoint-Received-SPF: 173.137.249.197 173-137-249-197.pools.spcsdns.net <moore@network-heretics.com> 5 none
Subject: Re: Registration of media type application/calendar+xml
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <4C8A7AB2.5090500@dcrocker.net>
Date: Sat, 11 Sep 2010 00:56:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D1B9008-8C93-4DFA-98AB-75BBE642964D@network-heretics.com>
References: <F842A373EE7E9C439CA07CCB01BBD1D0564C4899@TK5EX14MBXC138.redmond.corp.microsoft.com> <341B449F-7DFE-4A40-84B0-D008658A08DF@cs.utk.edu> <01NRP8H2AP2Y003JZ5@mauve.mrochek.com> <4C8A7AB2.5090500@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1081)
Cc: Steven Lees <Steven.Lees@microsoft.com>, Douglass Mike <douglm@rpi.edu>, "IETF@ietf.org" <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: Sat, 11 Sep 2010 04:55:51 -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.  

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

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

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

> As for the more abstract discussion about whether it's good or bad to have an xml version, I'll strongly suggest that it is best conducted in a real bar bof with real alcohol.  (I'll be supporting its existence, FWIW.)  

I had to read that twice.  For a second I thought you were offering to support the existence of alcohol for the bar bof. 

> The xml version is an important fact of life.  Let's not pretend otherwise.

My standard response whenever anyone cites anything as "reality" or a "fact of life", is that that's what people always say when they can't cite any technical justification.  

Keith