RE: "Replace and encrypt will be Recommended (optional)."

My gut reaction is forget about octet handling (for XML data only, steps
1 and 2) unless we hear that there is a need for it.  If applications need
the octets for XML data, they can serialize a returned nodeset.

I'd be glad to hear of reasonable scenarios where octet handling (for XML
data) is deemed valuable.  Otherwise, I'll probably just stick with my gut
reaction.

Ed
-- Original Message --

>To refocus this, let's consider just the decryption for the time being,
I've
>
>tweaked it as such (with all of whatever we decide to do required to 
>implement)
>
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-Processing-Decryption
>4. If it is an EncryptedData structure and the Type is "Element" or 
>"Content", then:
>1. return the octets of the decrypted data, or
>2. place the resulting octets as characters in place of the EncryptedData
>
>element with the encoding of the parent XML document
>3. return the nodeset (parsed form) of the decrypted data, or
>4. replace the EncryptedData element node with nodeset of the decrypted
data.
>Else (if not of type "Element" or "Content") provide the octets to the

>application
>
>In 2/4 there's an implicit return of the original document as octets or

>nodeset (or maybe just a pointer to that structure)...
>
>Which of these do we want? I think we agree we want XENC to provide octets
>
>or a nodeset, but with respect to the nodeset, should it be the original
>
>(transformed document), only the part that changed, or both?
>
>--
>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/
>
>

--------------------------------------------------
Ed Simon
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".

Received on Thursday, 2 August 2001 11:08:44 UTC