Comment on Transform simplification editors draft

(1) Status

replace "This is an initial editors draft" with more appropriate text.  
It has received WG review.

(2) General issue - is it acceptable to suggest extension through the  
addition of attributes? How will these new ones interoperate? will  
this lead to new complexity?

(3) General - add statements about backward compatibility?

(4) Section 1: /a simplified transform/an alternate/

(5) Section 2:

s/Each Reference/In the current XML Signature, Second Edition,  
processing model, each reference/

s/ This document does not refer to such application processing, but  
only the limited case of transforms defined and processed as part of  
the XML Signature process./What is referred to here is not such  
application processing steps, but only the limited case of transforms  
defined and processed as part of the XML Signature processing./

s/There are cases however where transforms must be applied as part of  
the signature process itself./There are cases however where  
transformations must occur as part of signature processing itself./

s/so we propose in this document to limit such processing/so we  
propose in this document to simplify such processing/

after the bullet list, s/Signature transforms are necessary/Well- 
defined signature processing  is necessary/

add to end of section 2:
"This exclusion is necessary. All is signed apart from the excluded  
portion, thus eliminating possibility of unwanted undetected additions."

(6) Section 3

Bullet 3
s/Define a limited selection of specific transforms, to avoid both  
performance penalties and security risks associated with a number of  
possible transformation technologies. /Avoid performance penalties and  
security risks associated with arbitrary transformations by  
restricting the possible transformation technologies. /

s/Such generality/As an alternative, such generality"
s/Signature/signature/ (same sentence)

(7) Section 3.2
s/culprit/culprit as/

(8) Section 4

s/Streaming issues/streaming issues/

(9) Section 4.2

s/One idea - is to use multiple digest values for one reference - one  
with each kind of canonicalization. E.g. canonicalizing with all  
spaces removed and all prefixes removed the digest value is YYY , but  
doing canonicalization the original way value is ZZZ./One idea is to  
use multiple simultaneous digest values for one reference - one with  
each kind of canonicalization. Specifically, one generated by  
canonicalizing with all spaces removed and the other with C14N11../

s/Also consideration for schema aware canonicalization TBD./Although  
schema aware canonicalization is another possibility, this may have  
issues related to requiring a schema./

Remove "Note" at end of 4.2

(10) Section 5

s/Transforms indicates a processing step/the term "transform" implies  
a processing step/

s/This new syntax maps /This new syntax can be mapped/
s/simply//

add to end ", if needed. Note however that not all 1.0 transformations  
can be expressed in a 2.0 format."

(11) Section 5.1

Clarify, only one Selection element, and only one URI.

Clarify only one Canonicalization element

s;Intersect->Subtract->Union;Intersect/Subtract/Union;

s/then while canonicalization/then while performing canonicalization/

(12) Reference to CSolc section of requirements, not reference by name?

(13) Section 5.3 remove last bullet on widgets.

(14) Section 5.4 , reference Boyer email content via URI

(15) Section 5.4.1

(16) Replace "xml" with "XML" throughout document, "html" with "HTML",  
"xpath" with "XPath"

(17) section 5.5
s/kind of//
s/well know/well known/

(18) the date of the document probably should be updated

Thanks


regards, Frederick

Frederick Hirsch
Nokia

Received on Tuesday, 13 January 2009 05:19:53 UTC