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). How does an intermediary know when its 
safe to remove a representation header ? Do all representation headers 
have to be targeted at the ultimate recipient to prevent dangling 
references ?

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

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

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

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

Marc.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.