Re: [apps-discuss] +exi

Peter Saint-Andre <> Tue, 13 December 2011 22:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 677AB21F8AF2 for <>; Tue, 13 Dec 2011 14:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.812
X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KCQZ6yvz+fR8 for <>; Tue, 13 Dec 2011 14:36:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 55B4821F8AF1 for <>; Tue, 13 Dec 2011 14:36:13 -0800 (PST)
Received: from (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id BCA954236A; Tue, 13 Dec 2011 15:43:47 -0700 (MST)
Message-ID: <>
Date: Tue, 13 Dec 2011 15:36:11 -0700
From: Peter Saint-Andre <>
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: Carine Bournez <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.3
OpenPGP: url=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc:, "" <>, Thomas Herbst <>
Subject: Re: [apps-discuss] +exi
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Dec 2011 22:36:14 -0000

On 12/13/11 2:58 PM, Carine Bournez wrote:
> On Tue, Dec 13, 2011 at 10:45:19AM -0700, Peter Saint-Andre wrote:
>> 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 is not exactly 2 modes. The EXI 1.0 Recommendation only specifies a 
> compressed encoding of an XML Infoset. Applications that include an EXI 
> processor may use different approaches around the encoding/decoding process. 
> So, you can have applications with a (text) XML document as an input
> (what you describe as #1), and applications that never use a text
> serialization (your #2).
>> 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.
> The W3C EXI Working Group has decided not to follow the +exi path, 
> since it involved a potentially infinite number of types to register.
> There could also be conformance issues: an EXI stream not encoded
> from a text version might not be necessarily serialized as a conformant
> "foo" after decoding from its EXI form. It needs some specification 
> work for each foo+exi.
> The generic application/exi content-type is meant to be used for cases 
> where there is no serialization from/to a standard format (then no 
> content-type can be used), as well as for protocols that have no 
> content-encoding capability.

Thank you for the clarifications.

The example that raised this issue for me was the ZigBee Alliance Smart
Energy Profile 2.0, which supports both a text serialization of their
XML format and an EXI representation. Tom Herbst and Paul Duffy can
describe that use case more accurately than I can, but based on what
you've said it seems that they would use application/sep+xml and note a
content encoding of EXI for the second case. However, it is possible
that (if their transport/transfer protocols do not have a way to note
the content encoding) they might use application/exi for the second
case. I'll let Tom and Paul speak to that. Zach Shelby might also have
opinions in the matter. In any case, I think they have the information
they need to make the right decision in the ZigBee Alliance (and if not
they can speak up).


Peter Saint-Andre