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: Mon, 18 Mar 2002 13:48:11 -0500
Message-Id: <200203181848.NAA05271@tux.w3.org>
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: merlin <merlin@baltimore.ie>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org


On Monday 11 March 2002 03:20, Takeshi Imamura wrote:
> >> ... If the xenc:EncryptedData is not the first node in X, and its
> >> type is neither &xenc;Element nor &xenc;Content, then it MUST
> >> be the only xenc:EncryptedData in X not referenced by an Except
> >> element. This prevents mixed decryption of XML and non-XML data,
> >> and restricts the decryption transform to a single piece of
> >> binary data at a time.
> I support Merlin.  Actually his suggestion is what I intended in the
> original text by "an xenc:EncryptedData element node being decrypted".
> That is, EncryptedData element nodes referenced by Except elements can
> appear anywhere in a node-set and should be ignored when checking if
> restrictions on the Type attribute are satisfied.  This is not only the
> case for non-XML EncryptedData element but the case for XML EncryptedData
> element.

The text now reads as follows, please propose further changes if necessary:

http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt
$Revision: 1.36 $ on $Date: 2002/03/18 18:45:50 $ GMT by $Author: reagle $

o If an xenc:EncryptedData being decrypted is the first node in X, the 
value of its Type attribute MUST NOT be &xenc;Content. This ensures the 
result is always rooted by a single element. 
If the xenc:EncryptedData is not the first node in X and its type is 
neither &xenc;Element nor &xenc;Content, then it MUST be the only 
xenc:EncryptedData in X not referenced by an Except element. This prevents 
the mixed decryption of XML and non-XML data and restricts the decryption 
transform to a single piece of binary data.
Received on Monday, 18 March 2002 13:48:16 GMT

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