On Friday 01 March 2002 12:05, merlin wrote: > We may need a fragment of text to further clarify XPointer support > when it is applied to a different document from the signature. > In such a case, here() is an error and the XPointer initial context > is the root of the new document? We don't have this problem with > XPointers in dsig because they always refer to the same document. I'm not sure I understand this, I'll defer to the authors. <smile/> > On a separate note, should we profile the decryption transform to > allow non-XML content (output is an octet stream)? We discussed the scenario below in September and Hiroshi suggested we would need a new function: Instead, we should define a new function that decrypts an xenc:EncryptedData element with a type other than Element or Content to an octet stream. Also we have to state that when such an xenc:EncryptedData element is being decrypted, the input to the transform has to be a node-set that has the xenc:EncryptedData element as the first node. http://lists.w3.org/Archives/Public/xml-encryption/2001Oct/0000.html As is my tendency I tend not to push for something unless someone says they want it. Hiroshi/Takeshi, is Merlin's usage scenario the same as what you were thinking? If so, would you like to propose some text? -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/Received on Friday, 1 March 2002 16:22:31 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:20 GMT