Re: Proposed Infoset Addendum to SOAP Messages with Attachments

I'm generally in favor of this approach but I think there are a couple 
of problems it doesn't adequately address:

(i) Attachments are an optimization to avoid having to base64 encode 
binary data. Section 8 of the proposal requires that 'signatures over 
elements with xbinc:Include children MUST be signatures over the base64 
data'. If you buy the premise that security in the form of DSIGs etc is 
going to be widely used then this requirement basically nullifies the 
advantage of using attachments since you'll have to run the base64 
encoding to compute and verify signatures.

I think a better approach would be a xbinc:Include aware XML DSIG C14N 
algorithm that just streams the binary data in the case of attachments 
(hence preserving the optimization) and does base64 decoding in the 
case of embedded data.

(ii) the current formulation misses an important facet of included 
attachments: their identity - i'll try to illustrate with a (contrived) 
example.

Consider an image processing application that can perform one or more 
transformations on an image, e.g. watermarking, color correction, 
resizing, etc. The application is deployed as a SOAP intermediary and 
SOAP header blocks are used to request transformation services.

I want to send a SOAP message that includes an image and I want to take 
advantage of the above image processing services. The image is large so 
I construct a MIME envelope in accordance with the SOAP messages + 
attachments spec and include my SOAP message and the image as content. 
The body of the SOAP message contains an insurance claim and includes 
the attachment as described in the infoset approach using the 
xbinc:Include element. The header contains a header block that requests 
image watermarking (or some other service) and also includes the 
attachment as described in the infoset approach using the xbinc:Include 
element.

In the current formulation, the intermediary will logically execute the 
xbinc:Include element and replace that element with the content of the 
attachment (base64 encoded) and then execute the transformation. 
Unfortunately this loses the link between the included data and the 
attachment (xbinc:Include/@href) so the intermediary will be unable to 
determine the identity of the attachment to replace with its output.

I suspect that a constrained use of the swa:Representation element 
might help with this problem - that is if there is only 1 
representation of a given resource in the MIME package the 
swa:Representation/@href can be used. Alternatively an application 
specific attachment reference mechanism could be used but that kind of 
defeats the purpose.

I think the root of this problem is that the semantic of the 
xbinc:Include/@href is value rather than reference based so multiple 
references to a single attachment result in multiple logical copies of 
the content in the XML infoset rather than multiple references.

Cheers,
Marc.


On Tuesday, Mar 25, 2003, at 12:41 US/Eastern, Martin Gudgin wrote:

>
> We have now posted the document illustrating an infoset approach to the
> attachment feature. You can find html[1], pdf[2] and word docs[3]. This
> document is intended to be a concrete realisation of the ideas laid out
> in the white paper at[4].
>
> Apologies for the delay.
>
> Gudge
>
> [1] http://www.gotdotnet.com/team/mgudgin/paswa/paswa.html
> [2] http://www.gotdotnet.com/team/mgudgin/paswa/paswa.pdf
> [3] http://www.gotdotnet.com/team/mgudgin/paswa/paswa.doc
> [4] http://www.xml.com/pub/a/2003/02/26/binaryxml.html
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Wednesday, 26 March 2003 11:18:39 UTC