Re: Proposed Infoset Addendum to SOAP Messages with Attachments

At 11:18 AM 3/26/2003 -0500, Marc Hadley wrote:

>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.

This is the same point I was getting at with my comment about "why 
base64".  Perhaps we can go to an extension of
XInclude that adds parse="base64" and parse="none" (or parse="binary" if 
you like).  The semantics of these would
be quite close to the current parse="xml" and parse="text", but for 
parse="none" you could not send the result through
an XML parser.

Breaking this out as a separate proposal, an extension of XInclude would 
also make the work going on here have more
leverage as it would provide a solution beyond SOAP and SwA.


>(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.

Well, the swa:Representation concept cannot truly apply to the case you 
outline here since it enables cached send-along of representations of 
resources.  What you have is a case of primary data transformation.  The 
solution is for "readers" and the
problem happens to "writers".


>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.

And the SwA 1.0 approach of referencing content internal to the package 
solves this problem with neither assumptions about 1 representation nor 
application specific mechanism.


>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.

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Wednesday, 26 March 2003 14:59:17 UTC