- From: Joseph Reagle <reagle@w3.org>
- Date: Fri, 1 Mar 2002 16:22:26 -0500
- To: merlin <merlin@baltimore.ie>, "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>
- Cc: xml-encryption@w3.org
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 UTC