- From: Don Brutzman <brutzman@nps.edu>
- Date: Tue, 26 Apr 2016 08:00:40 -0700
- To: "Peintner, Daniel (ext)" <daniel.peintner.ext@siemens.com>
- CC: "public-exi@w3.org" <public-exi@w3.org>
thanks for response prior to today's teleconference, very helpful. here are immediate reactions on technical issues to support dialog today. 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. >> >> ========================================================== >> 1. General questions: >> >> a. What implementations exist? >> >> ============================= > > In general most of the existing EXI implementation produce already canonical EXI streams. That said, there are some cases where Canonical EXI limits the freedom of the EXI spec to guarantee the same octet stream. sounds great. am wondering if a. EXI implementations might support an (EXI) to (EXI Canonical - EXIC?) mode. b. we might want to put such functionality on a server: XML->EXI, EXI->EXIC, EXIC validation, return trip >> b. Are there any test results? Is there a test corpus? >> >> ============================= > > There will be a test corpus. So far we just started the work. this information will be helpful to include in the CR announcement, including invitation to participate. >> d. A diagram comparing Canonical EXI use to Canonical XML use, for XML >> Encryption, would perhaps be illuminating. >> >> Perhaps similar to Figure D-1. Canonical EXI used in Signature. >> >> Shouldn't the envelope be included in this diagram? > > I agree that additional information and illustrations are helpful. > I will try to work on more diagrams for the non-normative sections. > Support their is always welcome! I will think about it, hopefully can sketch something out. >> ============================= >> >> e. Have we sought and received feedback comments from XML Security >> Working Group participants? >> >> [1] XML Security Working Group >> https://www.w3.org/2008/xmlsec >> >> ============================= > > We did receive feedback from people within the XML security working group that leaded to some proposal in Section "D.2 Exchange EXI Options". > More feedback would be appreciated though. Yes, we should specifically ask that group to respond. Individual responses are of course good, but a group response would seem to be appropriate since this is so closely connected. >> f. What implementation and testing work has been done with respect to >> XML Signature and XML Encryption? >> >> Of related interest: >> >> [2] Test cases for Canonical XML 2.0 >> W3C Working Group Note 18 June 2013 >> https://www.w3.org/TR/2013/NOTE-xml-c14n2-testcases-20130618 >> >> ============================= > > XML Signature and XML Encryption are more related to the EXI spec as mentioned in appendix section "B.1 Relationship to XML Security". Yes we need to elevate this issue to ensure that the Web of Trust works with XML or EXI (and in turn JSON). >> g. Has Canonical EXI been cross-checked with >> >> XML Signature Syntax and Processing Version 2.0 >> W3C Working Group Note 23 July 2015 >> https://www.w3.org/TR/2015/NOTE-xmldsig-core2-20150723 >> >> ============================= > > Canonical EXI based on XML infoset to ensure interoperability. The basis is good. We do need those experts to confirm it is satisfactory, or provide feedback/direction. I think that an application which integrates XML Signature and XML Encryption with EXI (and EXI for JSON) is likely to be very illuminating. >> h. Avoiding date-time canonicalization is debatable, and could lead to difficulties. >> >> If a document wants a well-formatted date, a string could be possible. >> >> Wondering, doesn't this mean a Canonical EXI processor would need to support >> all possible variations of a date, including various internationalization >> (I18N) languages? Hardly seems efficient. >> >> Comparison of two EXI streams with equivalent date values that are expressed >> in different forms would fail. Hardly seems canonical. >> >> We should look at how XML Canonicalization, XML Signature and XML Encryption >> handle dates. Perhaps XML Schema has a default form. >> >> I think we need date canonicalization. > > There has been a long debate on the mailinglist on whether to canonicalize date-time or not. The outcome was summarized in appendix section "B.3 No Date-Time Canonicalization". > > Already today XML signatures fail if the form of the string-based date-time differs! So yes, this should remain an open issue. One straightforward approach might be via a recommended practice: - strict form for dates - document designers can add an attribute to indicate date format as an additional piece of information. >> ============================= >> >> i. UnsignedInteger maximum value is problematic for floats and doubles, see below. >> >> ============================= > > According to my opinion EXI processors should not receive values that cannot be handled. Moreover, in case of EXI STRICT this situation exists already today. > > Note: EXI Float/Double have a limited range (The range of the mantissa is - (26^3) to 26^3-1 and the range of the exponent is - (2^14-1) to 2^14-1) Let's discuss and examine further please. >> j. url data type normalization is needed, otherwise consistent/canonical compararison. >> >> This probably should go in new section 4.5.9. >> >> Suggested reference: >> >> [3] Uniform Resource Identifier (URI): Generic Syntax >> IETF RFC 3986 >> https://tools.ietf.org/html/rfc3986 >> >> ========================================================== > > The XML schema datatype anyURI maps to EXI string. Most of the EXI processors do not have any knowledge about the underlying XML schema datatype. > Introducing such requirements may prevent the support of Canonical EXI in current processors. > > I could see that we add some information or best practices. Does this seem reasonable? > [...] Am hoping we can find something stricter that is part of the url datatype. 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, 26 April 2016 15:01:13 UTC