Re: [apps-discuss] +exi

Thomas Herbst <> Tue, 13 December 2011 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78AF211E80A4 for <>; Tue, 13 Dec 2011 15:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pu3YBEn5VUue for <>; Tue, 13 Dec 2011 15:00:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 00A6E11E809B for <>; Tue, 13 Dec 2011 15:00:15 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0EAFbY504KyAE+/2dsb2JhbABDrCSBcgEBBTo/EgEIDQEKHkIlAQEEAQkEBb43i2MEiDCSLoxd
X-IronPort-AV: E=Sophos;i="4.71,349,1320652800"; d="scan'208";a="8248183"
Received: from unknown (HELO ([]) by with ESMTP/TLS/AES128-SHA; 13 Dec 2011 15:00:14 -0800
Received: from ([fe80::b81e:2d5b:d263:6c44]) by ([::1]) with mapi; Tue, 13 Dec 2011 15:00:14 -0800
From: Thomas Herbst <>
To: Paul Duffy <>, Peter Saint-Andre <>
Date: Tue, 13 Dec 2011 15:00:12 -0800
Thread-Topic: [apps-discuss] +exi
Thread-Index: Acy56vjWCKAg05JrSiCdrdSBW2ettQ==
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 14 Dec 2011 08:03:43 -0800
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 23:00:16 -0000

Also, we are trying to be as http/coap agnostic as possible.

On 12/13/11 2:58 PM, "Paul Duffy" <> wrote:

>Peter accurately described SEP2's intentions re: EXI usage.  We're
>essentially marshaling/un-marshaling an  internal infoset either...
>1. direct to XML/text
>2. direct to an EXI binary encoding.  Note these nodes never manipulate
>XML text.  This approach is particularly important for resource
>constrained nodes (i.e. memory not available to blow the EXI up into XML).
>We tend to look at these as two different encodings, not one as a
>compression of the other.
>On 12/13/2011 4:36 PM, Peter Saint-Andre wrote:
>> 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
>>>> 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
>>> 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