Re: [apps-discuss] +exi

Thomas Herbst <therbst@silverspringnet.com> Tue, 13 December 2011 23:00 UTC

Return-Path: <therbst@silverspringnet.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 78AF211E80A4 for <apps-discuss@ietfa.amsl.com>; Tue, 13 Dec 2011 15:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu3YBEn5VUue for <apps-discuss@ietfa.amsl.com>; Tue, 13 Dec 2011 15:00:16 -0800 (PST)
Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 00A6E11E809B for <apps-discuss@ietf.org>; 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 IT-EXCA-02.silverspringnet.com) ([10.200.1.62]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 13 Dec 2011 15:00:14 -0800
Received: from IT-EXMB-01.silverspringnet.com ([fe80::b81e:2d5b:d263:6c44]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Tue, 13 Dec 2011 15:00:14 -0800
From: Thomas Herbst <therbst@silverspringnet.com>
To: Paul Duffy <paduffy@cisco.com>, Peter Saint-Andre <stpeter@stpeter.im>
Date: Tue, 13 Dec 2011 15:00:12 -0800
Thread-Topic: [apps-discuss] +exi
Thread-Index: Acy56vjWCKAg05JrSiCdrdSBW2ettQ==
Message-ID: <CB0D18D9.140B3%therbst@silverspringnet.com>
In-Reply-To: <4EE7D8AF.8060104@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
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 <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 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" <paduffy@cisco.com> 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
>>>>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
>>
>