Re: ACTION-22: Review EXI docs that were published

Ed,

did your review turn up any issues with the EXI spec that we should
raise with that working group?

Thanks,
-- 
Thomas Roessler, W3C  <tlr@w3.org>





On 2008-09-02 10:45:23 -0400, Ed Simon wrote:
> From: Ed Simon <edsimon@xmlsec.com>
> To: public-xmlsec@w3.org
> Date: Tue, 2 Sep 2008 10:45:23 -0400
> Subject: ACTION-22: Review EXI docs that were published
> List-Id: <public-xmlsec.w3.org>
> X-Spam-Level: 
> Archived-At: <http://www.w3.org/mid/002101c90d0a$8c0e20e0$9d00a8c0@XMLSEC004>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
> I have conducted a preliminary review of the Efficient XML Interchange (EXI)
> Format 1.0 (W3C Working Draft 28 July 2008). From that document...
>  
> >>>
>  
> The Efficient XML Interchange (EXI) format is a very compact, high
> performance XML representation that was designed to work well for a broad
> range of applications. It simultaneously improves performance and
> significantly reduces bandwidth requirements without compromising efficient
> use of other resources such as battery life, code size, processing power,
> and memory.
> The following design principles were used to guide the development of EXI
> and encourage consistent design decisions. They are listed here to provide
> insight into the EXI design rationale and to anchor discussions on desirable
> EXI traits.
> 
> General:
> 
> One of primary objectives of EXI is to maximize the number of systems,
> devices and applications that can communicate using XML data. Specialized
> approaches optimized for specific use cases should be avoided.
> 
> Minimal:
> 
> To reach the broadest set of small, mobile and embedded applications,
> simple, elegant approaches are preferred to large, analytical or complex
> ones. 
> 
> Efficient:
> 
> EXI must be competitive with hand-optimized binary formats so it can be used
> by applications that require this level of efficiency. 
> 
> Flexible:
> 
> EXI must deal flexibly and efficiently with documents that contain arbitrary
> schema extensions or deviate from their schema. Documents that contain
> schema deviations should not cause encoding to fail. 
> 
> Interoperable:
> 
> EXI must integrate well with existing XML technologies, minimizing the
> changes required to those technologies. It must be compatible with the XML
> Information Set [XML Information
> <http://www.w3.org/TR/2008/WD-exi-20080728/#XMLInfoset> Set], without
> significant subsetting or supersetting, in order to maintain
> interoperability with existing and prospective XML specifications.
> 
> <<<
>  
> It is noteworthy that the design principles of the EXI parallel much of the
> intentions of the W3C XML Security group. I see three potential areas to be
> addressed:
>  
> 1) Developing a design and protocol for an EXI-formatted XML Signature and
> XML Encryption for signing/encrypting EXI-formatted data.
> 2) Developing a design and protocol for an EXI-formatted XML Signature and
> XML Encryption for signing/encrypting regular XML and non-XML data. 
> 3) Developing a design and protocol for XML Signature and XML Encryption for
> signing/encrypting EXI-formatted data. 
> For 1) and 2) note that I do not expect that simply creating a plain XML
> Signature and EXI-ing it (and possibly the target data wrt 1)) will be
> sufficient because it would not be in concert with the EXI design
> principles. In other words, a question to be explored is whether an
> EXI-based profile of XML Signature (and possibly XML Encryption) might be
> necessary to use XML Signature and XML Encryption in accordance with EXI.
>  
> I have been thinking about the technical issues implied by the prior
> paragraph however I hesitate to express them here because I would like to
> test them more by actually playing with an EXI toolkit.
>  
> Because of the nature of EXI and the potential complexity in considering the
> relationship among EXI, XML Signature, and XML Encryption, I would recommend
> that the analysis of EXI be an ongoing project within the group.
>  
> Regards,
> Ed
>  
> _____________________________
> Ed Simon <edsimon@xmlsec.com>
> Principal, XMLsec Inc. 
> (613) 726-9645 
> 
> Interested in XML, Web Services, or Security? Visit "
> <http://www.xmlsec.com/> http://www.xmlsec.com". 
> 
> New! "Privacy Protection for E-Services" published by Idea Group (ISBN:
> 1-59140-914-4 for hard cover, 1-59140-915-2 for soft cover). 
> Includes a chapter, by Ed Simon, on "Protecting Privacy Using XML, XACML,
> and SAML".
> See the Table of Contents here: " <http://tinyurl.com/rukr4>
> http://tinyurl.com/rukr4".
>

Received on Tuesday, 2 September 2008 14:45:51 UTC