RE: xbinc:Include and identity

> From: Marc Hadley
> 
> I'd like to restart the stalled thread[1] on "Proposed Infoset
Addendum
> to SOAP Messages with Attachments". I don't think the current proposal
> fully describes the relationship between attachments and xbinc:Include
> elements wrt attachment identity. I'll try to illustrate via an
example
> (MIME envelope not shown for brevity):
> 
> <soap:Envelope xmlns:...>
> 	<soap:Header>
>          <xbinc:DoInclude
> 
> soap:role='http://www.w3.org/2002/12/soap-envelope/role/next'
>              soap:relay='true' />
> 		<n:data
> 
> soap:role='http://www.w3.org/2002/12/soap-envelope/role/next'
>              soap:relay='true' >
> 			<n:photo1 xmime:MediaType='image/png'>
> 				<xbinc:Include
> href='cid:http://example.org/me.png' />
> 			</n:photo1>
> 		</n:data>
>          ...
> 	</soap:Header>
> 	<soap:Body>
> 		<m:data'>
> 			<m:photo1 xmime:MediaType='image/png'>
> 				<xbinc:Include
> href='cid:http://example.org/me.png' />
> 			</m:photo1>
> 		</m:data>
> 	</soap:Body>
> </soap:Envelope>
> 
> Note that the same image is referenced from a header block and the
body.

Hypothetically, assume we require the value of xbinc:Include/@href to be
unique within an Envelope -- one include per part. Let's see what that
assumption would buy us in terms of the questions below.

> Some questions:
> 
> (i) If this message passes through an intermediary should I expect the
> values of the href attributes to be preserved along with the
> corresponding content-ID and/or content-location fields in the MIME
> envelope?

No. Since header blocks and the body don't share parts, an intermediary
can safely re-serialize the Infoset representation of a header block or
the body using different @href values.

> (ii) After passing through an intermediary should I expect there to
> remain a single attachment or is the intermediary at liberty to
> reserialize each instance of the xbinc:Include as separate attachments
?

Intermediaries would fault if they detected that a part was included > 1
time and would always (re-)serialize the Infoset with one part per
include.

> (iii) If an intermediary encrypts the header containing the attachment
> should I expect the attachment in the body to also be encrypted ?

No. The element in the Infoset that contains the include defines the
only transformations, type, etc. of the included part.

Revisiting the one-part-per-include assumption, it appears to simplify
the processing issues you raise.

That invites the question: if we make this assumption, how does one
reference content from within > 1 place within the Envelope? One
approach is to have a named place within the Infoset where the content
is included, and have the other places within the Envelope refer to (ala
xs:anyURI, not include) that place. The Representation element in PASWA
does this. This approach addresses concerns about on-the-wire efficiency
as well as concerns about modeling shared identity within the Infoset.

Received on Thursday, 17 April 2003 20:50:02 UTC