RE: Proposed resolution for issue 440

 

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] 
> Sent: 07 November 2003 21:15
> To: Martin Gudgin
> Cc: noah_mendelsohn@us.ibm.com; Xml-Dist-App@W3. Org
> Subject: Re: Proposed resolution for issue 440
> 
> On 7 Nov 2003, at 12:56, Martin Gudgin wrote:
> >> I agree the model works well when there's a 1-1 correspondence 
> >> between attachments and references to those attachments in 
> the SOAP 
> >> message.
> >> But what if I need to reference the same data from multiple places.
> >> It's suggested that the way to do this is to use a representation 
> >> header plus two or more application specific references 
> (some element 
> >> or attribute of type anyURI).
> >
> > WRT the application specific references, this is exactly 
> how SwA works.
> >
> Right, so... ?

So you are no worse off with the Representation header model that you
would have been with 'other attachment technologies'

> 
> >> How
> >> does an intermediary know when its safe to remove a representation 
> >> header ?
> >
> > By appeal to the SOAP processing model. If you want a 
> Representation 
> > header to be available to multiple roles, either because 
> you have URIs 
> > that reference it in headers targeted at different roles, 
> or because 
> > you have URIs that reference it in headers and the body, you would 
> > have a Representation header targetted at 'none'.
> >
> Right, the problem is that the references to representation 
> headers are invisible to the SOAP processing model and the 
> binding so the application has to shoulder the burden of 
> making sure that referenced representations survive as long 
> as the references to them. 

No. If something is targetted at 'none' it NEVER gets removed. So the
application has no burden.

> Include references don't suffer 
> this problem but as currently specified they fail to preserve 
> attachment cardinality in the presence of intermediaries. 

I have proposed a solution to that problem: Make the mapping 1:1.

> I 
> think it should be possible to unify the model to remove the 
> distinction between Include references and references to 
> representation headers while preserving attachment 
> cardinality through intermediary processing.

Wouldn't the require us to put ALL the binary data into headers? I don't
want to go there.

> 
> >>
> >>> Now consider what happens if we allow parts not referenced
> >> by the SOAP
> >>> envelope into the "related" package.  How do we know what
> >> do do with
> >>> them at intermediaries?  How do we know whether to sign 
> them with a 
> >>> dsig?
> >>> Etc.,
> >>> etc.
> >>>
> >> MTOM doesn't tell you what to do in this case but another 
> >> specification could. Requiring 1-1 between includes and 
> attachments 
> >> prevents such future extensibility. To be clear I'm not suggesting 
> >> that MTOM needs to address the case of attachments that are not 
> >> referenced by an Include, just that it shouldn't prevent it.
> >
> > What is the visibility of such parts at the SOAP layer?
> >
> That depends on what you mean by the SOAP layer. I'm tempted 
> to say minimal/none but I don't want that taken out of 
> context. In the abstract it would be something akin to the 
> att:SecondaryPartBag property of the attachment feature. Such 
> attachments would not take part in the SOAP processing model 
> but an application would be able to get at the attachments by 
> reference to the received MIME package. How access to that is 
> provided would be implementation dependent.

So we're back to things being in the message but not part of the
infoset. As I said earlier in this thread, if we end up there, then as
far as I am concerned we might as well not have bothered to do MTOM. The
value of MTOM to me is that everything is in the infoset. If there is
ANYTHING outside the infoset, then for me, it's value drops pretty close
to zero.

> 
> >>
> >> As for signatures, again I agree that the model works well when 
> >> there's a 1-1 correspondence between attachments and references to 
> >> those attachments in the SOAP message. But what if I need to 
> >> reference the same data from multiple places.
> >> Assuming the representation header approach, when I sign a 
> portion of 
> >> the message that contains an application specific 
> reference (the URI 
> >> of the represented data) then I just sign the reference, not the 
> >> data. I'd like to extend the value of Include so that 
> signatures over 
> >> secondary references to the an attachment (currently an 
> app specific 
> >> anyURI) get the same benefits as signatures over the primary 
> >> reference (the Include).
> >
> > Surely you would just put two ds:Reference elements into your 
> > ds:SignatureInfo, one for the Representation header and one for the 
> > element/attribute that references it...
> >
> But that requires the entity doing the signing to be aware 
> that the element/attribute is actually a reference to a 
> representation header.

And?

> The Include mechanism in MTOM removes this requirement for 
> the primary reference to the attachment, 

I don't understand what you mean when you say 'primary reference to the
attachment'. In MTOM all binary data is inlined in the infoset. There is
no notion of 'attachments', only inline binary data. There is a
referencing mechanism at the *serialization* layer to make this work,
but this reference is not visible to the application.

> I'd like to unify 
> things so that secondary references work the same way.

See above.

Gudge

Received on Saturday, 8 November 2003 08:54:48 UTC