- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Tue, 22 Aug 2000 18:06:08 -0400
- To: "John Boyer" <jboyer@PureEdge.com>
- Cc: "XML DSig" <w3c-ietf-xmldsig@w3.org>, <jboyer@csr.csc.UVic.CA>
At 13:25 8/22/2000 -0700, John Boyer wrote: >Attached is a copy of the latest editors' copy of the XML DSig specification, except that I have added and deleted the text necessary to implement the new Reference/Transform processing model discussed in the most recent teleconference. Cool. >The sections of HTML surrounded by <u></u> and <strike></strike> Other readers might find this useful to see your additions: (css is convenient!) 1. s/john="john"/class="john"/ 2. u.john {color:green;} >4) Rewrote text of all Transforms such that they indicate whether they input and output an octet stream or a node-set. Rewrote text surrounding DigestMethod so that it is clear that if the input is not an octet stream, then the node-set gets canonicalized. Meaning that we are not requiring an explicit C14N? (It's implied?) Regarding Don's comments from the call, do we need a "parse me" transform that explicitly represents the conversion of octects to node-sets prior to xml processing, or will this be implicit to the subsequent XML transform? >8) I now distinguish between Canonical XML and Canonical XML with Comments. This was really quite necessary to get everything to work and keep all of the features we used to have. Canonical XML with Comments is recommended, not required. As well, it seemed like it wouldn't hurt anything because Minimal canonicalization would be quite difficult if comments had to be omitted. I'm not sure about this (or calling it 'parameterization'). If someone wants to include comments, they have the option, but I don't think it needs to be spoken of in the Signature spec even, just makes things seem more complex. >9) The C14N Draft needs to be changed. Rather than taking an octet stream representing the document plus taking an optional XPath expression to filter the document, it will now take an octet stream or node-set as input, along with an optional flag that tells whether or not comments should be omitted from the output. For the octet stream case (which is the one everyone's really focused on right now), the stream will be converted to a node-set AS CURRENTLY DEFINED as long as the comment flag is FALSE. The identifier (URL for C14N)#WithComments will be created within the C14N document. Again, I fear this comment issue will cause confusion, and people will wonder whether to include them. If an application wants to keep them, it can simply specify its own XPath, but providing this option will just re-invite people to discuss the nature of comments because they will worry which they should use. _________________________________________________________ Joseph Reagle Jr. W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/People/Reagle/
Received on Tuesday, 22 August 2000 18:11:13 UTC