Re: Comments: Canonical EXI -- Last Call Working Draft

Youenn,

Thank you for your suggestion. Please forgive my candor, but that sounds like a real hack to me. I would only resort to cutting and pasting headers onto EXI documents as a last resort if I had no other option. And in cases where we dynamically change EXI options based on input messages or other conditions, matching the right Canonical EXI headers with the right Canonical EXI bodies would significantly raise complexity and require repeated transmissions of Canonical EXI headers (that ultimately aren’t even needed). We have not yet poured the concrete over the EXI Canonicalization specification, so lets try to get it right and not plan to make people with legitimate use cases hack around its limitations.

Second, the users I’m talking about already have more sophisticated, more efficient and more secure ways of ensuring the same EXI options and schemas were used. They do not need the EXI header at all and any effort required to create and/or transmit and/or process it is wasted effort. That’s the penalty.

The solution to the problem is simple. Let’s retain the existing flexibility of the EXI format by keeping the options document optional. Don’t force a single solution on everyone. This will satisfy all the requirements of those that need the EXI options document and those that don’t. It will allow everyone to implement the strength of security they need for their use case, including those that need stronger security than that provided by including the EXI options and schema ID in the header.

 Cheers,

 John

> On Oct 2, 2015, at 1:35 AM, FABLET Youenn <Youenn.Fablet@crf.canon.fr> wrote:
> 
> Hi John, all,
>  
> I do not really see where is the penalty.
> It seems reasonable for your users to send a EXI stream that would contain whatever EXI header they like AND a Canonical EXI body. 
> Generation of the Canonical EXI document (only meaningful at validation time in that case) would be done by doing binary concatenation of the canonical EXI header (transmitted out-of-band) and the received EXI body.
>                 y
>  
> That said, there is no "on-the-wire" penalty and the added processing cost is really limited.
> 
>  
> That is not correct. There can be a significant on-the-wire penalty for those that want the efficiencies associated with using Canonical EXI as their wire format. This is an important use case we should support without unnecessary performance penalties.

AgileDelta, Inc.
john.schneider@agiledelta.com
http://www.agiledelta.com