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 >> >
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Graham Klyne
- Re: [apps-discuss] font/* Eric Burger
- Re: [apps-discuss] font/* Eric Burger
- [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Mark Nottingham
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Mykyta Yevstifeyev (М. Євстіфеєв)
- Re: [apps-discuss] font/* Murray S. Kucherawy
- Re: [apps-discuss] font/* Murray S. Kucherawy
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Graham Klyne
- Re: [apps-discuss] font/* Barry Leiba
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* Murray S. Kucherawy
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Paul Hoffman
- Re: [apps-discuss] font/* Lyndon Nerenberg
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* Eric Burger
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Peter Saint-Andre
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Bjoern Hoehrmann
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Bjoern Hoehrmann
- Re: [apps-discuss] font/* John C Klensin
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Dave CROCKER
- Re: [apps-discuss] font/* Tony Hansen
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Julian Reschke
- Re: [apps-discuss] font/* Barry Leiba
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Frank Ellermann
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] font/* Graham Klyne
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] font/* Tony Hansen
- Re: [apps-discuss] font/* Julian Reschke
- [apps-discuss] 答复: font/* TianLinyi
- Re: [apps-discuss] font/* Tony Hansen
- Re: [apps-discuss] 答复: font/* Tony Hansen
- Re: [apps-discuss] font/* Nathaniel Borenstein
- Re: [apps-discuss] font/* Martin J. Dürst
- Re: [apps-discuss] font/* Martin J. Dürst
- [apps-discuss] type name suffixes (was: Re: font/… Peter Saint-Andre
- Re: [apps-discuss] 答复: font/* Vinayak Hegde
- Re: [apps-discuss] font/* Ned Freed
- Re: [apps-discuss] type name suffixes (was: Re: f… Ned Freed
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] type name suffixes Peter Saint-Andre
- Re: [apps-discuss] type name suffixes Ned Freed
- Re: [apps-discuss] type name suffixes Larry Masinter
- Re: [apps-discuss] type name suffixes Peter Saint-Andre
- Re: [apps-discuss] type name suffixes Bjoern Hoehrmann
- [apps-discuss] +exi (was: Re: type name suffixes) Peter Saint-Andre
- Re: [apps-discuss] +exi (was: Re: type name suffi… Bjoern Hoehrmann
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi (was: Re: type name suffi… Zach Shelby
- Re: [apps-discuss] +exi (was: Re: type name suffi… Mark Nottingham
- Re: [apps-discuss] +exi (was: Re: type name suffi… Carsten Bormann
- Re: [apps-discuss] +exi (was: Re: type name suffi… Mark Nottingham
- Re: [apps-discuss] +exi (was: Re: type name suffi… Zach Shelby
- Re: [apps-discuss] +exi (was: Re: type name suffi… Mark Nottingham
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi SM
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Julian Reschke
- Re: [apps-discuss] +exi Carine Bournez
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Mark Nottingham
- Re: [apps-discuss] +exi Carine Bournez
- Re: [apps-discuss] +exi Paul Duffy
- Re: [apps-discuss] +exi Thomas Herbst
- Re: [apps-discuss] +exi Zach Shelby
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Paul E. Jones
- Re: [apps-discuss] +exi Carine Bournez
- Re: [apps-discuss] +exi Zach Shelby
- Re: [apps-discuss] +exi Martin Thomson
- Re: [apps-discuss] font/* t.petch
- Re: [apps-discuss] +exi Paul Duffy
- Re: [apps-discuss] +exi psaintan
- Re: [apps-discuss] +exi Zach Shelby
- Re: [apps-discuss] +exi Paul Duffy
- Re: [apps-discuss] +exi Peter Saint-Andre
- Re: [apps-discuss] +exi Bjoern Hoehrmann
- Re: [apps-discuss] +exi Henry S. Thompson
- Re: [apps-discuss] +exi Ned Freed
- Re: [apps-discuss] +exi Bjoern Hoehrmann
- Re: [apps-discuss] +exi Ned Freed