Edit comment LC-3070 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-3070

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:

4. Section 3: As mentioned above, making the EXI options document and
the EXI schemaId mandatory in every canonical EXI document is at odds
with the efficiency objectives of EXI. In many or perhaps even most
use cases that require efficiency, these can be (and are) provided
out of band or specified by a higher-level protocol. As such, including
them in every canonical EXI message introduces unnecessary overhead
and provides no value since all cooperating nodes already have this
information.

Furthermore, forcing the inclusion of a schemaId in every message does
not actually solve the problem of ensuring the sender and receiver use
the same schemas. The EXI schemaId is not guaranteed to be unique and
would be easy for a sender and receiver to end up using the same schemaId
for two different versions of the same schema or even two completely
different schemas (breaking any signature that depends on schemaId).
There are more reliable ways to ensure senders and receivers are using
the same schemas for encoding/decoding EXI documents. This problem is
not unique to EXI canonicalization and the EXI canonicalization
specification should not force a specific, sub-optimal solution on EXI
users. As with EXI, users should be allowed to use the EXI options
document and schemaId to address this issue, but they should not be
forced to do so if they have a better, more efficient solution that
is already working.

Related issues: (space separated ids)

WG Notes:

Resolution: The WG acknowledges there is a desire and need to allow applications to choose whether they use header options and schemaId in the canonical form.

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