W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2001

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

From: <edsimon@xmlsec.com>
Date: Thu, 2 Aug 2001 11:07:45 -0400
Message-ID: <3B5F179F00002F32@mail.san.yahoo.com>
To: Joseph M. Reagle Jr. <reagle@w3.org>, Takeshi Imamura <IMAMU@jp.ibm.com>
Cc: XML Encryption WG <xml-encryption@w3.org>, Blair Dillaway <blaird@microsoft.com>
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

-- Original Message --

>To refocus this, let's consider just the decryption for the time being,
>tweaked it as such (with all of whatever we decide to do required to 
>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
>Else (if not of type "Element" or "Content") provide the octets to the

>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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:04 UTC