Re: [apps-discuss] +exi

Peter Saint-Andre <stpeter@stpeter.im> Tue, 13 December 2011 17:45 UTC

Return-Path: <stpeter@stpeter.im>
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 CD69321F8B02 for <apps-discuss@ietfa.amsl.com>; Tue, 13 Dec 2011 09:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.187
X-Spam-Level:
X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ZHvKKVuW00GQ for <apps-discuss@ietfa.amsl.com>; Tue, 13 Dec 2011 09:45:21 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ECE9621F8AFF for <apps-discuss@ietf.org>; Tue, 13 Dec 2011 09:45:20 -0800 (PST)
Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 329304236A; Tue, 13 Dec 2011 10:52:55 -0700 (MST)
Message-ID: <4EE78F2F.2070601@stpeter.im>
Date: Tue, 13 Dec 2011 10:45:19 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Zach Shelby <zach@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> <EDB50792-348B-4693-9FDF-04BA091F8BE9@sensinode.com>
In-Reply-To: <EDB50792-348B-4693-9FDF-04BA091F8BE9@sensinode.com>
X-Enigmail-Version: 1.3.3
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: paduffy@cisco.com, Thomas Herbst <therbst@silverspringnet.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] +exi
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: Tue, 13 Dec 2011 17:45:21 -0000

Restarting this thread to get closure...

On 11/15/11 8:21 PM, Zach Shelby wrote:
> 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.

I chatted with a few folks about this in Taipei and afterward.

As I understand it (correct me if I'm wrong), EXI has two modes:

1. Straight compression of the text representation of XML (text in,
EXI-compressed data out). To make use of the data, you then decompress
it back into the angle-brackety text representation of XML that we all
know and love.

2. Direct, binary representation of the XML infoset. In this case, you
never have the data in a angle-brackety text representation, instead it
is always a binary representation.

It seems to me that #1 is similar to gzip, i.e., the textual
representation is encoded using EXI compression, so we'd have this:

   Content-Type: application/foo+xml
   Content-Encoding: exi

It seems to me that #2 might not be an encoding of the relevant +xml
content type, but might be a different content type, so +exi might be
appropriate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/