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

I am wondering what exactly the specification is preventing your users from doing.

From what I understand, your users will be happy just sending EXI headers + canonical EXI bodies.
The spec allows this (and is mostly about defining that actually), which is good to me.
If one wants a name for that practice, one can for instance use “EXI stream with a canonical EXI body”.

The specification also defines another thing which adds one more constraint to the EXI stream (namely that the header is also canonical). The specification is giving it the name “Canonical EXI stream”.

One reason IIRC of adding this notion is that the working group thought that, in general, it is good practice for the signature validation to also validate the complete set of EXI options, including the schema ID.

                Y

From: John Schneider [mailto:jcs@agiledelta.com]
Sent: vendredi 2 octobre 2015 20:06
To: public-exi-comments@w3.org
Subject: 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<mailto: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<mailto:john.schneider@agiledelta.com>
http://www.agiledelta.com