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

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:

2. Section 1, last sentence: Change “… whether two documents are identical …” to
“… whether two documents are equivalent …”

3. Section 1.2: We agree EXI canonicalization is important for EXI
environments that cannot afford to revert to traditional XML
canonicalization methods. In addition, we recommend you mention some
of the ways EXI canonicalization is useful for traditional XML users.
For example, EXI canonicalization provides the first type-aware
canonicalization scheme that can discern that +1, 1, 1.0, 1e0 and 1E0
are equivalent representations of the same floating-point value. This
allows intermediaries to use binding-models and/or type-aware processing
without breaking signatures. In addition, with a fast EXI processor,
EXI canonicalization can be much faster than traditional XML
canonicalization and can help cure some of the well-known XML security bottlenecks.

6. Section 4.2.1: Change “Prune productions” to “Select productions” in heading.
Pruning productions will remove them from the grammars, changing the event codes
of the following events and causing incompatibility with the EXI 1.0 specification.
I expect the specification intends to specify which productions must be selected
rather than removing productions from the grammars.

7. Section 4.2.2: Change “Prune productions” to “Select productions” in heading.
The word “prune” should also be replaced in the body of this section. See above rationale.

9. Section 4.2.3: Change heading “Use the event with the most accurate event”
to “Use the event that matches most precisely” or something similar. Current
wording is unclear.

14. Section 4.4.6: The last sentence in the second paragraph states that EXI
processors must first try to represent the string value as a local hit and
when this is not successful as a global hit. It might be useful to clarify
that one of the reasons the attempt to represent the string value as a local
hit may fail is because the string has already been used as a local hit
previously. EXI supports only one local table hit per value.

Related issues: (space separated ids)

WG Notes:

Resolution: Agreed and implemented.

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