RE: Proposed resolution for issue 440

 

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] 
> Sent: 07 November 2003 14:09
> To: noah_mendelsohn@us.ibm.com
> Cc: Martin Gudgin; Xml-Dist-App@W3. Org
> Subject: Re: Proposed resolution for issue 440
> 
> On 6 Nov 2003, at 18:34, noah_mendelsohn@us.ibm.com wrote:
> 
> > Let's say we adopt Gudge's rule of
> > 1-to-1 between xbinc:Include and parts in the "related" 
> group.  What's 
> > the rule for intermediaries?  Simple:  the content is 
> logically in the 
> > Infoset.  Let's assume a header with MTOM content is not removed at 
> > the intermediary.  If you go out over a non-MTOM binding, 
> you send the 
> > characters (or whatever your binding does.)  If you go over an MTOM 
> > binding, then you MAY continue to carry the binary as a 
> part (or MAY 
> > fail to optimize on the 2nd hop.)  The two bindings MAY conspire to 
> > optimize the copying of bytes from the inbound stream to 
> the outbound.  
> > Now, let's assume the header is removed:  the rule is very 
> clear, even 
> > if the outbound binding is MTOM, there clearly MUST NOT be a part 
> > corresponding to the received binary.  So with Gudge's 
> rule, the SOAP 
> > processing model tells you exactly what to do.
> >
> 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.

> 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'.

> Do all representation headers have to 
> be targeted at the ultimate recipient to prevent dangling references ?

I don't think so, see above.

> 
> > 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?

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

> 
> > I have mixed feelings about whether to allow multiple 
> xbinc:Includes 
> > to reference a single part, but can easily live with our 
> decision of 
> > yesterday to say "only one reference per part".
> 
> I'm not convinced that this is good enough.

good enough for what?

> 
> > I quite strongly feel
> > that Gudge is right that the value of MTOM/PASWA is that most all 
> > semantically interesting message content is logically in 
> the envelope 
> > Infoset.
> >
> I agree. I don't think this value is diminished by allowing 
> extensibility though.

At the risk of repeating myself, I think the value is diminished
significantly.

Gudge

Received on Friday, 7 November 2003 12:57:05 UTC