RE: Proposal for multi-reference support in MTOM

I think the crux of our disagreement is that I do not see
xbinc:Include/@href as being a reference. And so I don't think it should
be treated in the same way as application level URI values ( which I do
see as being references ).

But I'm beginning to repeat myself.

Gudge

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: 19 November 2003 08:38
> To: Martin Gudgin
> Cc: Xml-Dist-App@W3. Org
> Subject: 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.
>

Received on Wednesday, 19 November 2003 11:47:53 UTC