RE: Additional Canonical EXI comment

Hi Frederick,

Thank you for your insightful comments on EXI C14N.

Please find below our response to items (2) (4) (5) (6).
There will be another installment covering the rest to be made shortly.

[1] http://lists.w3.org/Archives/Public/public-exi/2013Oct/0000.html

Thanks,

taki


> (2) In section 2.4 the following is not clear
> 
> "However, due to increased code footprint and processing complexity, 
> Canonical EXI processors MUST support only EXI input streams that use 
> the according datatype representation already. Be aware of this restriction 
> when passing EXI streams to a recipient that is required to create the 
> canonical EXI form."
> 
> Does it mean the following?
> 
> "Canonical EXI processors MUST be able to process input streams that only 
> support String representations. The reason is to allow simpler and smaller 
> implementations. This restriction is important when passing a stream to 
> an implementation that creates a canonical EXI form."

The first sentence in your paraphrased version does not quite represent
what was intended to mean by the original. The WG plans to sort out 
descriptions currently present in sections 2.2 and 2.4 in a way to avoid 
leading to a confusion.

Also, in lieu of the paragraph containing the above cited sentences in 
section 2.4, we plan to describe essentially the same in a different form 
such as follows, hoping it would cause less confusion.

"EXI 1.0 permits the use of untyped AT or CH terminal symbols to represent 
 a value content item even when a typed AT or CH terminal symbol is available 
 that could have been used to represent the value. Therefore, given an input 
 value content item that uses an untyped AT or CH terminal symbol despite 
 the availability of a typed alternative terminal symbol, it is not apparent 
 whether the use of the untyped terminal symbol was due to the result of 
 observing the event selection rule described in Section 2.2 EXI Event 
 Selection or otherwise (i.e. negligence of observing the rule) unless 
 switching to the typed alternative terminal symbol is actually attempted 
 by a Canonical EXI processor. To cope with this situation, Canonical EXI 
 processors SHOULD be able to convert an untyped value into each of the 
 datatype representations defined in EXI 1.0 as long as the target datatype 
 representation can accept the value."


> (4) The section "Resolutions" might better be named "Assumptions"
>

The WG plans to change the title to "Design decisions" to reflect that
it contains assumptions, rationales and decisions. BTW, the section is 
to be turned into an appendix section after some retrofitting.


> 4.1 typo, replace "The working group conducted " with "The working group concluded "
>

Thank you. We have fixed this in the internal draft accordingly.


> 4.3 why is plain text XML an issue for EXI canonicalization (Canonical 
> XML can be used for XML)

Canonical EXI assumes EXI event sequences as its inputs to apply an EXI 
encoding rule much more restricted than the one that is available in EXI 1.0 
specification. We decided to have Canonical EXI be focused on that task, 
therefore, it does not do the kind of massaging that Canonical XML provides, 
such as attribute value normalization or removal of superfluous namespace 
declarations. Because of this, Canonical XML would need to be applied prior to
Canonical EXI in order for Canonical EXI to be useful in scenarios involving 
text XML. There may be scenarios that may find that combination useful, 
but they are likely to be ones that involve both text XML and EXI, which are 
still ones that use EXI. We are not sure if Canonical EXI brings real benefits 
to scenarios that exclusively uses text XML (hence no EXI) for document 
exchanges.


> consider removing: "However, character model normalization may become 
> an issue when working with plain-text XML."
>
> (5) References
> 
> I think referencing Canonical XML 1.1 might be more appropriate than 1.0: 
> http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/

You will see these changes in the next publication.


> (6) Specification cover page
>
> I was surprised not to see a link to an Editors draft nor to be able to 
> find one from the EXI WG home page, I would expect such a link.

Thank you for mentioning this. The page now contains a link to Canonical EXI.



-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Tuesday, October 01, 2013 12:59 PM
To: public-exi@w3.org
Cc: Frederick.Hirsch@nokia.com; public-xmlsec@w3.org
Subject: Additional Canonical EXI comment

I have additional question/comments on the "Canonical EXI" FPWD specification, http://www.w3.org/TR/exi-c14n/

(1) How are the choice of EXI Options and Schema Options recorded with the canonical form - so for example, it can be archived and the signature verified at a later time? 

Perhaps this should be defined as part of the Canonical EXI specification, to make explicit the options that matter to canonicalization and how they are recorded with the canonical form.

If only known out of band this could severely limit the use cases for which signatures would be useful.

(2) In section 2.4 the following is not clear

"However, due to increased code footprint and processing complexity, Canonical EXI processors MUST support only EXI input streams that use the according datatype representation already. Be aware of this restriction when passing EXI streams to a recipient that is required to create the canonical EXI form."

Does it mean the following?

"Canonical EXI processors MUST be able to process input streams that only support String representations. The reason is to allow simpler and smaller implementations. This restriction is important when passing a stream to an implementation that creates a canonical EXI form."

(3) It might be helpful in section 3.2 to indicate how the recipient distinguishes the ds:Signature element (containing signature value and algorithm/hash information) from the EXI stream and thus excludes it from the calculation. 

Presumably this is done via the ds:Reference in the signature referring to the enclosing EXI document and thus acting as an enveloped signature, though a detached signature should also be possible.

(4) The section "Resolutions" might better be named "Assumptions"

4.1 typo, replace "The working group conducted " with "The working group concluded "

4.3 why is plain text XML an issue for EXI canonicalization (Canonical XML can be used for XML)

consider removing: "However, character model normalization may become an issue when working with plain-text XML."

(5) References

I think referencing Canonical XML 1.1 might be more appropriate than 1.0: http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/

[[

Canonical XML Version 1.1 is a revision to Canonical XML Version 1.0 to address issues related to inheritance of attributes in the XML namespace when canonicalizing document subsets, including the requirement not to inherit xml:id, and to treat xml:base URI path processing properly.

]]


(6) Specification cover page

I was surprised not to see a link to an Editors draft nor to be able to find one from the EXI WG home page, I would expect such a link.

I hope these comments are helpful

regards, Frederick

Frederick Hirsch
Nokia

===

Earlier comment:

Not a technical comment, but I notice that the "Canonical EXI" specification should include references to XML Signature 1.1 and XML Encryption 1.1 when referenced in section 3.1

e,g, "EXI Canonicalization may be used as a canonicalization method algorithm in XML Signature [XMLDSIG-CORE1] and XML Encryption [XMLENC-CORE1]."

along with the corresponding references

http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/

http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/


====

Received on Thursday, 17 October 2013 00:17:04 UTC