RE: Additional Canonical EXI comment

Hi Frederick,

With regards to the point on the relationship between canonical EXI and
text XML, we will address it along the line of your suggestion in the next
publication.

Thank you for providing all the comments and suggestions.

taki


-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Thursday, October 17, 2013 11:54 AM
To: Takuki Kamiya
Cc: Frederick.Hirsch@nokia.com; public-exi@w3.org; public-xmlsec@w3.org
Subject: Re: Additional Canonical EXI comment

Taki

comments inline

thanks for your detailed reply

regards, Frederick

Frederick Hirsch
Nokia



On Oct 16, 2013, at 8:08 PM, ext Takuki Kamiya wrote:

> 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.
> 

good


> 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."
> 

this is certainly much clearer. Thanks.

> 
>> (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.
> 
> 

That sounds appropriate.

>> 4.1 typo, replace "The working group conducted " with "The working group concluded "
>> 
> 
> Thank you. We have fixed this in the internal draft accordingly.
> 

thanks

> 
>> 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.
> 

Perhaps you should document this in the introduction. What you've written would probably work if you remove the last sentence and add a stronger statement 
like "Canonical EXI should not be used with plain text XML since it assumes EXI event sequences as input."

> 
>> 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.
> 

thanks

> 
>> (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.
> 

thanks

> 
> 
> -----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 Wednesday, 23 October 2013 20:54:29 UTC