Re: [apps-discuss] +exi (was: Re: type name suffixes)

Zach Shelby <zach@sensinode.com> Wed, 16 November 2011 03:21 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5221B11E80F8 for <apps-discuss@ietfa.amsl.com>; Tue, 15 Nov 2011 19:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level:
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkfXLWAwNxHo for <apps-discuss@ietfa.amsl.com>; Tue, 15 Nov 2011 19:21:42 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3911E80E2 for <apps-discuss@ietf.org>; Tue, 15 Nov 2011 19:21:41 -0800 (PST)
Received: from dhcp-123b.meeting.ietf.org (dhcp-123b.meeting.ietf.org [130.129.18.59]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id pAG3LRVc023722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 05:21:33 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-656--490897481; protocol="application/pkcs7-signature"; micalg=sha1
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <lu96c7hsl37325nn3184ub4vr88qjgja50@hive.bjoern.hoehrmann.de>
Date: Wed, 16 Nov 2011 11:21:25 +0800
Message-Id: <EDB50792-348B-4693-9FDF-04BA091F8BE9@sensinode.com>
References: <4EBBB0EE.8050502@it.aoyama.ac.jp> <01O88YVG6MQY00RCTX@mauve.mrochek.com> <4EBCCE76.2090807@it.aoyama.ac.jp> <01O8AM6GDT5000RCTX@mauve.mrochek.com> <4EC0CCAE.5070402@stpeter.im> <01O8EWMK2T8E00RCTX@mauve.mrochek.com> <4EC2DC42.7010307@stpeter.im> <01O8GE5O3B5K00RCTX@mauve.mrochek.com> <C68CB012D9182D408CED7B884F441D4D0611DAC31D@nambxv01a.corp.adobe.com> <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im> <lu96c7hsl37325nn3184ub4vr88qjgja50@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1084)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] +exi (was: Re: type name suffixes)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 03:21:47 -0000

On Nov 16, 2011, at 11:06 AM, Bjoern Hoehrmann wrote:

> * Peter Saint-Andre wrote:
>> So, let's say I have "foo" data that can be represented in either plain
>> old XML or as EXI. If I send that "foo" data as plain old XML, the
>> "application/foo+xml" media type is right. If I send that "foo" data as
>> EXI, the "application/foo+exi" media type seems wrong, and so does the
>> "application/exi" media type (just as "application/xml" would not be
>> right for the first encoding). Sure, I don't particularly want to
>> duplicate all "+xml" entries with "+exi" entries, but I don't think that
>> every protocol or community that sends around XML data will also send
>> around EXI-encoded data.
> 
> The idea is that "EXI" is more like "gzip", so with HTTP you would do
> 
>  Content-Type: application/foo+xml
>  Content-Encoding: exi
> 
> As you would for gzip-compressed content.

Ouch, don't do that. 

The main interest right now for EXI is in constrained networks, and in particular over CoAP. We don't have support for indicating content-encoding in CoAP. Besides, the current media type for EXI is application/exi. Thus it would make perfect sense to have +exi entries. Furthermore, EXI is totally different than gzip, which is a generic encoding that can be applied to anything. EXI can be applied only to XML objects, and in particular EXI is often used in a schema mode where it is only applicable to a single schema. Thus the form application/schema+exi makes even more sense, as that EXI format is actually specific to that particular schema and the media type tells you everything that is needed to decode the representation. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297