W3C home > Mailing lists > Public > xml-encryption@w3.org > May 2002

Re: Decryption Transform processing question

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 30 May 2002 12:13:44 -0400
To: merlin <merlin@baltimore.ie>
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020530161345.3E947718@policy.w3.org>

On Wednesday 29 May 2002 07:36 pm, merlin wrote:
> However, all these changes boil down to a large refactoring
> of the decryption transform spec; and, if I am unique in
> my viewpoint, then I am at an impasse and must cede to the
> majority view and stand by my former stated views on the
> subject.

I think this is a great discussion; it's what happens when "implementors 
hit the spec." <smile/> Beyond your new requirement which I'll address in a 
separate email, I'm generally happy with the direction of what you propose, 
but I'm most interested in the thoughts of other implementors, which at 
this point [1] include IBM and Phaos

[1] http://www.w3.org/Encryption/2002/02-xenc-interop.html

1. In the present WD, we say we support the xmldsig profile XPtr (which is  
same-document XPointers '#xpointer(/)' and '#xpointer(id('ID'))'. Anything 
else is optional. You seem to be using more sophisticate pointers, are you 
advocating a change in this level of support? (BTW: I think I've heard that 
folks are reviving the XPtr work by breaking it into different 
profiles/specs.) I'd prefer to keep this real simple and rely upon IDs.
2. In decryptIncludedNodes() why did you switch the order of steps 2 and 3? 
(Makes it difficult to see the diffs, but maybe you had a reason.)
3. In decryptXML, if I have three elements I'm decrypted, via process one 
do they all go into one octet stream, or is a group of 3 octets sets?


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 Thursday, 30 May 2002 12:14:23 UTC

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