ACTION-22: Review EXI docs that were published

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".