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

Re: Why is Except limited to local fragments?

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 8 Mar 2002 13:22:45 -0500
Message-Id: <200203081822.NAA20025@tux.w3.org>
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>, merlin <merlin@baltimore.ie>
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
On Friday 08 March 2002 03:03, Takeshi Imamura wrote:
> I basically agree on this, but I think we should state such a restriction
> on X in Section 2.1.2.  I tried to make some tweak to Section 2, which is
> attached below.  Could you check if I misunderstand anything?
> (See attached file: 20020308.html)

Looks good, now in the editors' draft [1]. My two questions:

1. Do we even need to talk about Z? According to decryptIncludedNodes, Z is 
always a nodeset, but it's not even mentioned in the "if XML" in step 2, 
and it is mention in the "if octets" in step 3.
2. I'm a little confused by this wording, "If an xenc:EncryptedData element 
node being decrypted is the first node in X, the value of its Type 
attribute MUST NOT be  xenc;Content. Otherwise, the value MUST be  
xenc;Element or  xenc;Content."

Can we be confident that we have the ordering of the nodes in X?

Perhaps we should give a little motivation (to help me and eventually 
others understand). Perhaps,

If an xenc:EncryptedData element node being decrypted is the first node in 
X, the value of its Type attribute MUST NOT be  xenc;Content. This prevents 
an ill-formed XML document with element content appearing at the start of 
the document. If the xenc:EncryptedData is not the first node in X, the 
value MUST be  xenc;Element or  xenc;Content. This prevents binary data 
from appearing out of place in an XML document. 

??

-- 

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, 8 March 2002 13:22:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:20 GMT