Re: [apps-discuss] +exi

Carine Bournez <carine@w3.org> Tue, 13 December 2011 21:58 UTC

Return-Path: <carine@jay.w3.org>
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 7E09F11E80A2 for <apps-discuss@ietfa.amsl.com>; Tue, 13 Dec 2011 13:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
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 uRIVN1GLJsKr for <apps-discuss@ietfa.amsl.com>; Tue, 13 Dec 2011 13:58:29 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9309B11E809D for <apps-discuss@ietf.org>; Tue, 13 Dec 2011 13:58:25 -0800 (PST)
Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from <carine@jay.w3.org>) id 1RaaMa-0003Op-RJ; Tue, 13 Dec 2011 16:58:16 -0500
Date: Tue, 13 Dec 2011 16:58:16 -0500
From: Carine Bournez <carine@w3.org>
To: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <20111213215816.GI5525@jay.w3.org>
References: <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> <4EE78F2F.2070601@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EE78F2F.2070601@stpeter.im>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: paduffy@cisco.com, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Thomas Herbst <therbst@silverspringnet.com>
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 22:01:02 -0000

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.


-- 
Carine Bournez -+- W3C Europe