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

Re: xbinc:Include and identity

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Thu, 08 May 2003 12:34:02 -0400
To: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
Cc: xml-dist-app@w3.org
Message-id: <E0A0949A-8172-11D7-9596-0003937568DC@sun.com>

Restarting this thread now that the IPR hurdle appears to have been 
cleared.

On Thursday, Apr 17, 2003, at 20:49 US/Eastern, Jeffrey Schlimmer wrote:

>> 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.
>
That's probably fine for content-ID but I'm not sure if the same 
applies to content-location ? Perhaps the intent is that Include/@href 
only be used with the cid: scheme ? If so this needs to be explicitly 
stated.

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

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

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

> 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.
>
Yes, but it raises other questions.

1) I'd like to be able to generate data binding code from message 
schema. The proposed xmime:Binary type lets me generate suitable 
mappings for the single place where the data is included but doesn't 
cover the situation where I have multiple references to the data. The 
current formulation suggests use of an application specific referencing 
mechanism for each additional reference to the binary data, a 
standardized xmime:BinaryRef type would be more useful for tooling 
purposes and would also allow for better verification of references on 
message receipt.

2) The semantics of message security in the presence on Include and 
references needs to be carefully considered. If I sign part of a 
message containing an xbinc:Include then I probably want to sign the 
actual data rather than the Include EII itself. If I sign part of a 
message that includes references to representation elements then 
presumably I'm only signing the reference, not the referenced data ?

Regards,
Marc.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Thursday, 8 May 2003 12:35:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT