Edit comment LC-3069 for Efficient Extensible Interchange Working Group

Quick access to LC-3041 LC-3042 LC-3043 LC-3044 LC-3045 LC-3065 LC-3066 LC-3067 LC-3068 LC-3069 LC-3070 LC-3071 LC-3072 LC-3073 LC-3074 LC-3075 LC-3076 LC-3077 LC-3078

Comment LC-3069

Comment Shortname:

Commenter: John Schneider <john.schneider@agiledelta.com>

Message-id:

Section of the document concerned:

[Free text description]Document as a whole1. Introduction Canonical EXI Abstract 1.1 Notational Conventions and Terminology 1.2 Need of Canonical EXI 1.3 Applications 1.4 Limitations 2. Canonical EXI Stream 3. Canonical EXI Header 4. Canonical EXI Body 4.1 EXI Alignment Options and Streams 4.2 EXI Event Selection 4.2.1 Prune productions according to specific conventions 4.2.2 Prune productions for non applicable events with content values 4.2.3 Use the event with the most accurate event 4.3 EXI Stream Order 4.4 EXI Datatypes 4.4.1 Unsigned Integer 4.4.2 Enumeration 4.4.3 Decimal 4.4.4 Float 4.4.5 Date-Time 4.4.6 String and String Table 4.4.7 Restricted Character Sets 4.4.8 Datatype Representation Map A Design Decisions A.1 Relationship to XML Security A.2 No Unicode Normalization B Canonical EXI Examples B.1 EXI Event Selection Example B-1. Example productions with event codes B.2 EXI Stream Order Example B-2. Attribute and Namespace Declaration Sorting Figure C-1. Canonical EXI used in Signature B.3 EXI Floats Example B-3. Example algorithm for converting float values t... Example B-4. Canonicalized EXI Float values C Canonical EXI Applications C.1 Signature Processing Steps C.2 Exchange EXI Options (Best Practices "Work in Progress") C.2.1 Option 1 - XML Signature element C.2.2 Option 2 - Uri scheme fragment identifier C.2.3 Option 3 - EXI options within EXI stream D References
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody Bournez, Carine Brutzman, Don Cokus, Michael Fernández, Javier D. Heuer, Joerg Käbisch, Sebastian Kamiya, Takuki Kuntschke, Richard Matsukura, Ryuichi McGregor, Don Peintner, Daniel Quin, Liam Shah, Grishma ZERGAOUI, Mohamed

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

1. Architecture & Design: The specification defines canonical EXI with
respect to an input EXI stream. This limits one’s ability to use canonical
EXI with traditional XML or other XML Infoset representations and creates
a poor architectural fit with the rest of the XML stack of technologies
that are defined with respect to the XML Infoset. The strict dependency
on an EXI input stream, the EXI options document and the EXI schemaId
creates intrinsic incompatibilities with XML, which does not support
these EXI-specific artifacts. This leads to practical implementation
problems, such as the inability for canonical EXI to support digital
signatures through XML intermediary nodes, which you identified at the
end of section A.1.

To be useful in all XML contexts and with all XML technologies, EXI
canonicalization must be defined with respect to the XML Infoset. We
recommend you update the specification to define canonical EXI with
respect to a given XML Infoset, a given XML Schema and a given set of
EXI options. The schema and EXI options may be provided any number of
ways, as you describe well in section C.2. As with EXI, the user should
be allowed to embed these in the EXI header when it is advantageous,
but should not be required to do so when it is not. Mandating the
inclusion of the EXI options and a schemaID in every message is at
odds with EXI’s efficiency objectives and makes it onerous to use
canonical EXI as a transmission format. As you point out in section
C.1., using canonical EXI as a transmission format can eliminate
the need to perform [redundant] canonicalization at the receiver —
further increasing efficiency. We have users that currently employ
canonical EXI this way and it is very advantageous to them. However,
requiring the EXI options and schemaId in every message would quickly
overwhelm the benefits of using canonical EXI as a transmission format.

5. Section 4: As stated above, to be useful in all XML contexts and with
all XML technologies, EXI canonicalization must be defined with respect to
a given XML Infoset rather than a given EXI stream. The semantics of the
specification should be specified with respect to a given XML Infoset,
a given XML Schema and a given set of EXI options (independent on how
these are acquired).

15. Section A.1: The second paragraph states that Canonical EXI deals with
EXI documents. As alluded in the third paragraph of this section, this is
not strictly true. Canonical EXI should be usable with and provide benefits
to XML, EXI or any other XML Infoset representation. However, as stated
earlier in these comments, canonical EXI must be defined with respect to
the XML Infoset rather than an EXI input document to achieve this. Defining
EXI canonicalization with respect to only EXI is limiting and fails to
realize the full potential of the technology.

The last sentence in this section also states that it is not possible to
use XML on intermediary nodes when Canonical EXI has been used for signing.
This is a limitation of the current specification and not of canonical EXI
in general. If you define canonical EXI with regard to a given XML Infoset,
XML Schema and given set of EXI options and ensure all EXI nodes use the
same XML Schema and EXI options, this limitation goes away. As stated earlier,
there are more reliable and efficient ways to ensure cooperating nodes use
the same XML Schemas and EXI options than including the EXI options document
and schemaId in every message. And these methods do not fail when transcoding
to XML because they do not depend on the XML/EXI message for the schema and
EXI options. The reason the current specification fails in this regard is
because it depends strictly on the EXI document to carry the options and
schemaId and transcoding to XML loses this information. As discussed earlier,
this is a design flaw that should be fixed.

Related issues: (space separated ids)

WG Notes:

Resolution: We agree with your comment that Canonical EXI should be based on XML Infoset and changed the specification accordingly.

(Please make sure the resolution is adapted for public consumption)