- From: Don Brutzman <brutzman@nps.edu>
- Date: Tue, 3 May 2016 08:23:45 -0700
- To: "Peintner, Daniel (ext)" <daniel.peintner.ext@siemens.com>
- CC: "public-exi@w3.org" <public-exi@w3.org>
pending from prior discussion: a. canonicalization of dates. am hoping we can simply use XML Schema default form. ... we had a good discussion and resolution of that today. still pending from before: b. canonicalization of url. perhaps https://tools.ietf.org/html/rfc3986 c. what are range limits for floats/doubles? On 4/26/2016 5:41 AM, Peintner, Daniel (ext) wrote: > Hi Don, > > Thank you very much for your thorough review. > Please find comments inline. > > Thanks, > > -- Daniel > >> Thanks for the great work on the Canonical EXI Recommendation draft. >> Review follows. >> >> ========================================================== >> [...] >> ========================================================== >> >> 2. Editorial comments: >> >> ============================= skipped agreements... >> ============================= >> section 1.2, last sentence: >> >> "can help cure some of the well-known XML security bottlenecks." >> to >> "can help address some of the well-known processing bottlenecks for XML security." > > Agree. > >> Is there a reference for such bottleneck issues? >> >> An additional, separate motivating paragraph for XML Signature and XML Encryption would be useful here. > > I did not find a good reference while it seems to be clear for many people that XML security causes processing bottlenecks. perhaps we should open an issue for future EXI working group demonstration? >> ============================= >> 1.4 Limitations >> >> "based on the knowledge of the used EXI options" >> to >> "based on the applicable EXI options" > > I believe that this modification would change the meaning. how to fix? >> ============================= >> 3. Canonical EXI Header >> >> third paragraph >> >> append comma after >> "A Canonical EXI Header MUST NOT begin with the optional EXI Cookie" > > Agree. > >> ============================= >> numbered item 3: >> >> "When the alignment option compression is set, pre-compress MUST >> be used instead of compression." >> >> Since this statement is counterintuitive and somewhat puzzling, adding a >> brief reason would be helpful to the reader. Perhaps: >> >> "This setting prevents further compression during processing of >> the Canonical EXI stream that might eliminate further information, as >> described in ____section___. > > I would suggest adding the following note: > "EXI Compression uses the standard DEFLATE Compressed Data Format defined by RFC 1951 which does to define a canonical representation." ok by me >> ============================= >> numbered item 4 Note paragraph: >> >> "Nevertheless the burden of requiring the schemaId element has >> been found justifiable due to the increased security." >> >> append >> " and strict representations of Canonical EXI" > > I am not sure about the intent of the addition? clarity... indicating that strict representations need schemaID. i think that forward compatibility clearly makes this necessary. we don't want early canonicalizations to break if/when schema version changes. >> ============================= >> 4.1 EXI Alignment Options and Stream, >> >> second paragraph last sentence, >> >> "using the alignment option pre-compression." >> append >> "using the alignment option pre-compression instead." > > Agree. > [...] >> ============================= >> "Note: >> >> Optimizations such as pruning insignificant xsi:type values (e.g., >> xsi:type="xsd:string" for string values) or insignificant xsi:nil values >> (e.g., xsi:nil="false") are prohibited for a Canonical EXI processor." >> >> not clear why this is the case, please explain > > For example adding xsi:nil="false" to many elements is possible. That said it does not change the document given that value is false. Optimized processors might remove such xsi:nil="false" attributes to reduce the stream size. Canonical EXI forbids remving such attributes. > > Do you have a proposal to make it clearer? Remove it? It is just a note and previous statements such as "SHALL NOT change the input sequence" say already the same. fine by me, thanks for explanation >> ============================= >> 4.5.1 Unsigned Integer >> >> "Canonical EXI processors MUST use the Unsigned Integer datatype >> representation even if a value goes beyond the value 2147483647." >> >> What are expectations and requirements if this occurs? > > The EXI specification allows you to fallback to string OR to still represent it as a sequence of octets terminated by an octet with its most significant bit set to 0. > > Canonical EXI requires you to represent it as a sequence of octets. > >> Respective handling (where to truncate) would seem to be different >> when representing the components of a float. >> >> This limits floating point numbers to ~9 significant digits of accuracy? >> >> What about doubles? > > EXI float/doubles have already limited ranges in the EXI spec (see https://www.w3.org/TR/exi/#encodingFloat). > >> Maximum/minimum expressable values need to be clearly listed for each derived type. >> >> Seems like a significant problem that needs to be addressed. Perhaps >> consecutive Unsigned Integer values for higher resolution. > > I am not sure about the proposal. > >> ============================= >> 4.5.3 Decimal >> >> add further requirements as bullets: >> >> - Omit leading zeroes in integral portion. >> - Omit trailing zeroes in fractional portion. > > In typed encoding the above stated requirements happen already. > In the EXI Decimal representation there is no way to represent leading nor trailing zeroes. ok >> ============================= >> 4.5.4 Float >> >> "If A2 and B are equivalent per the rule 1 above, A and B are equivalent." >> to >> "If A2 and B are equivalent values per the rule 1 above, A and B are equivalent." >> >> However I'm not convinced that the second rule shifting exponents for comparison >> is correct. If leading and trailing zeroes are handled consistently, won't the >> mantissa values (all of the significant digits) always be the same? > > We explored these rules and I think it should be OK. Do you have an example/illustration which causes issues... >> ============================= >> >> A number of reference entries are missing "W3C Recommendation", "W3C Working Group Note" etc. > > Shall we add those information? I checked the EXI spec and we did not do so in the past. > see https://www.w3.org/TR/exi/#References and >> ============================= >> >> URL values do not need trailing slash character. >> >> ============================= > > I usually add "slash" for directories while I do not add any slash for files such as "rfc2119.txt". > That said, I think it does not really matter.. W3C style rules should govern these >> ============================= >> Unclear, more explanation is needed please: >> >> "Caution: The primary objective of Canonical EXI has been to eliminate >> the associated overhead of plain-text XML when building a canonical form. >> This means that in the case of signing Canonical XML, EXI can be used on >> intermediary nodes. On the contrary, it is not always possible to use XML >> on intermediary nodes when Canonical EXI has been used for signing." > > I added an e.g., superfluous namespace declarations may be deleted as it is the case in Canonical XML. > EXI does not delete any namespace declaration! OK [...] >> Wondering if redundant definition of EXI Option values in both signature >> and the document is yet another option? > > I think this implicitly allowed. One can send an EXI stream with schema information but the signature is built without schema knowledge or other options. ok >> ============================= >> D.2 Exchange EXI Options (Best Practices) >> >> (at end of document) >> >> Need to conclude this section somehow, the reader is left hanging. >> >> Perhaps D.2.4 Decision Criteria or somesuch. >> >> ========================================================== > > Mhh, any good proposal? > What about the following: > > "D.2.4 Decision Criteria > > The previous subsections provide best practices how to exchange EXI options but use-cases are not limited to the afore mentioned proposals." Sounds good, confirms context of the section that it is optional practice. Again thanks for steady and diligent progress. all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
Received on Tuesday, 3 May 2016 15:24:26 UTC