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

There are certainly technical issues that could be important, but before
committing to fully exploring those, we should discuss the validity of the
use cases (see 1) to 3) in my prior email) with the EXI WG. 

Ed
_____________________________
Ed Simon <edsimon@xmlsec.com>
Principal, XMLsec Inc. 
(613) 726-9645 

Interested in XML, Web Services, or Security? Visit "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".

-----Original Message-----
From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On
Behalf Of Thomas Roessler
Sent: September 2, 2008 10:45
To: Ed Simon
Cc: public-xmlsec@w3.org
Subject: 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 16:24:17 UTC