W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2003

Re: Proposed Infoset Addendum to SOAP Messages with Attachments

From: John J. Barton <John_Barton@hpl.hp.com>
Date: Wed, 26 Mar 2003 11:59:10 -0800
Message-Id: <>
To: Marc Hadley <Marc.Hadley@Sun.COM>, Martin Gudgin <mgudgin@microsoft.com>
Cc: xml-dist-app@w3.org

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:55 UTC