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

Re: XML decryption transform number 13

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Mon, 17 Jun 2002 12:45:29 +0900
To: merlin <merlin@baltimore.ie>
Cc: reagle@w3.org, xml-encryption@w3.org
Message-ID: <OF27CE97B0.1B777B3E-ON49256BDB.000F5701@LocalDomain>


>>>         2. Copy Y in place of e in Z.
>>According to XPath's data model, this is not possible because Y and Z are
>>yielded from different documents.  Merlin's technique, i.e., serializing
>>and Z and parsing the resultant octet stream, would be needed.
>Hi Takeshi,
>I respectfully disagree with you here, although if you can
>refer me to where the XPath document states that this is not
>possible, I'll willingly relent.

The XPath spec does not state that it is impossible, but it does not also
state that it is possible.

>Joseph's text implies that you take the document structure and
>a node set over it and copy these nodes into another document,
>duplicating the structure where possible. I don't see anything
>that precludes this; how it is done is left, as it should be,
>to the implementor.

I understand what Joseph and you intend, but I don't think that it is so
easy to describe.  That is because the XPath data model does not suppose
that any nodes are copied or imported from another document.  What does
"copy these nodes into another document, duplicating the structure where
possible" mean formally?  How can it be broken down using the XPath
vocabularies?  If we define our vocabularies for describing it, it would be
OK.  However, I'm not sure whether that is worth doing, considering efforts
for it.

>Are you suggesting that decrypt-and-replace is not possible? If
>so, why are you not asking that the entire concept be removed
>from the specification?

No.  It is possible.  I'm not concerned about its possibility but its

>By explicitly leaving this non-normative text vague, as Joseph
>does, any given implementation can do what it needs to do. If
>it cannot perform this operation, then it does not support
>the decrypt-and-replace mode.
>What you suggest; i.e., serialize and parse; does not
>correspond to decrypt-and-replace, it corresponds to the
>creation of a new document. That's not what we are trying to
>specify; we're trying to specify, as abstractly as possible,
>how to replace nodes in the original document with a decrypted
>node set, without actually mandating any given implementation.

Tokyo Research Laboratory
IBM Research
Received on Monday, 17 June 2002 00:52:14 UTC

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