Re: Proposal for multi-reference support in MTOM

On 18 Nov 2003, at 21:02, Martin Gudgin wrote:
>
> I have to say that I don't think it has any benefit over the
> Representaion header approach. I still have to add an attribute to my
> element. In your proposal it's a mtom:ContentID, in the Representation
> header case it's any attribute you like provided it's of type 
> xs:anyURI.
> In both cases I can deal with multiple references and only send a 
> single
> copy of the data.
>
The benefits over the representation header approach are as follows:

(i) It brings the benefits of attachment inclusion to all references to 
the data, not just to the representation header or the single reference 
elsewhere in the message.

(ii) Attachments are automatically removed when there are no more 
references to them, the representation header approach can easily 
result in attachments being kept for the whole message path because of 
a 'none' role (more on this below).

(iii) It provides a single mechanism for referencing data rather than 
one mechanism when we only have a single reference and another when 
there are multiple.

> Where you proposal diverges is that I think it makes life very hard for
> intermediaries. It essentially requires them to parse the whole 
> message,
> looking for xbinc:Include elements and/or mtom:ContentID attributes. I
> don't want intermediaries to have to trawl through headers not 
> targetted
> at them or the body. And with your proposal they would have to do that.

I disagree. If your intermediary just wants to remove a particular 
header without looking at the rest of the message and that header 
happens to have an Include then the worst you'll end up with is an 
orphaned attachment. The representation header approach can also easily 
end up with the same thing where the only reference to an attachment is 
a representation header targeted at 'none' (more on this below).

> With the Representation header we can target given representations at
> specific roles, and also have Representations intended for 'everyone' 
> by
> targeting them at 'none'.
>
Using a representation header with a role of anything except 'none' 
will require intimate knowledge of the processing at every intermediary 
in the message path in order to ensure that representation headers are 
not removed while they are still referenced from elsewhere in the 
message. I don't think this is realistic in practice and we'll end up 
with most if not all representation headers being targeted at 'none'. 
This means that all such attachments will be present for the whole 
message path - one of the benefits of MTOM was to avoid this.

> Regarding signatures, I regard it as a feature, not a bug, that I can
> sign the reference seperately from the referenced data. With the
> Representation header I
> essentially get to choose. I can sign the reference, the data or both.
>
It might be a feature, just not a good feature ;-). I'd question the 
value of signing a reference alone. One of the key benefits of MTOM is 
the inclusion of the data itself in signatures. The problem with the 
representation approach is that the entity constructing a signature 
needs to know that an instance of an xs:anyURI is in fact a reference 
to a representation and to include that representation in the signed 
info. With the Inclusion (and my proposed multiple inclusion) approach 
this comes for free.

Marc.

>
>> -----Original Message-----
>> From: xml-dist-app-request@w3.org
>> [mailto:xml-dist-app-request@w3.org] On Behalf Of Marc Hadley
>> Sent: 12 November 2003 12:47
>> To: Xml-Dist-App@W3. Org
>> Subject: Proposal for multi-reference support in MTOM
>>
>> Here's a proposal for an extension to the current MTOM
>> formulation to offer better support for multiple inclusion of
>> the same data. The proposed extension  has the following properties:
>>
>> - Preserves MTOM semantics of attachment inclusion in SOAP
>> message infoset
>> - Supports existing 'Include' and 'Representation' semantics,
>> use of extension is optional
>> - Supports multiple inclusion of attachments without
>> replication of data in the serialized form
>> - Multiply included data replicated in message infoset,
>> signatures over elements containing such data include
>> attachment data rather than a reference to the data as woud
>> be the case when using a Representation approach.
>>
>>
>> Infoset Form
>> ============
>>
>> This section shows via an example the infoset of a message
>> after the binding has performed the MTOM deserialization
>> (described later). XML 1.0 is used as the most convenient
>> syntax to express the infoset but this should be considered a
>> purely abtract model of the message content.
>>
>> <env:Envelope xmlns:env="..." xmlns:mtom="...">
>>    <env:Body>
>>      <app:Stuff xmlns:app="...">
>>        <app:Thing1 mtom:ContentID="someURI">
>>          some base64 text
>>        </app:Thing1>
>>        <app:Thing2 mtom:ContentID="someURI">
>>          some base64 text
>>        </app:Thing2>
>>        <app:Thing3>
>>          some base64 text
>>        </app:Thing3>
>>      </app:Stuff>
>>    </env:Body>
>> </env:Envelope>
>>
>> Note that the same base64 data is included as the content of
>> the Thing1 and Thing2 EIIs, this is indicated by the value of
>> the mtom:ContentID attribute being the same for both. Thing3
>> has no mtom:ContentID indicating that the optional
>> multi-reference extension is not being used for the content
>> of this EII.
>>
>>
>> Optimized (MIME) Wire Form
>> ==========================
>>
>> This section shows via an example the serialized form of a
>> message using the MIME based MTOM.
>>
>> Content-type: multipart/related; boundary="someBoundaryString"
>>
>> --someBoundaryString
>> Content-Type: application/soap+xml
>>
>> <env:Envelope xmlns:env="..." xmlns:mtom="...">
>>    <env:Body>
>>      <app:Stuff xmlns:app="...">
>>        <app:Thing1 mtom:ContentID="someURI">
>>          <mtom:Include href="someURI">
>>          <!-- depending on how mtom:ContentID is defined, the
>> Include/@href may be redundant -->
>>        </app:Thing1>
>>        <app:Thing2 mtom:ContentID="someURI">
>>          <mtom:Include href="someURI">
>>        </app:Thing2>
>>        <app:Thing3>
>>          <mtom:Include href="someOtherURI">
>>        </app:Thing3>
>>      </app:Stuff>
>>    </env:Body>
>> </env:Envelope>
>>
>> --someBoundaryString
>> Content-Type: image/png
>> Content-ID: someURI
>>
>> binary picture data
>>
>> --someBoundaryString
>> Content-Type: image/png
>> Content-ID: someOtherURI
>>
>> binary picture data
>>
>> --someBoundaryString--
>>
>>
>> Schema Types
>> ============
>>
>> <complexType name="OptimizationCandidate">
>>    <simpleContent>
>>      <extension base="xsd:base64Binary">
>>        <attribute name="ContentID" type="xsd:anyURI"/>
>>        <attribute name="MediaType" type="xsd:string"/>
>>        <!-- other attributes we define -->
>>      </extension>
>>    </simpleContent>
>> </complexType>
>>
>> Terminology
>> ===========
>>
>> The following terminology is used in the description of the
>> serialization and deserialization algorithms:
>>
>> Optimization candidate:
>>    EII of type xsd:base64 or mtom:OptimizationCandidate.
>>
>> Matching MIME part:
>>    MIME part whose content-id and/or content-location headers
>> (TBD specify exact matching criteria) match an
>> OptimizationCandidate/@ContentID.
>>
>> Content:
>>    base64Binary child CIIs of an optimization candidate (excludes AII
>> children)
>>
>>
>> Infoset to Wire Serialization
>> =============================
>>
>> For each optimization candidate in the SOAP message
>>      - if no matching MIME part exists then create a matching
>> MIME part
>> from the optimization candidate's decoded content and AIIs
>>      - replace the content of the optimization candidate with a child
>> mtom:Include EII
>>
>>
>> Wire to Infoset Deserialization
>> ===============================
>>
>> For each mtom:Include EII
>>      - replace the mtom:Include EII with base64 encoded attachment
>> content
>>
>> --
>> Marc Hadley <marc.hadley@sun.com>
>> Web Technologies and Standards, Sun Microsystems.
>>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.