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

>> 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. Include 
references don't suffer this problem but as currently specified they 
fail to preserve attachment cardinality in the presence of 
intermediaries. 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.

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

>>
>> 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. 
The Include mechanism in MTOM removes this requirement for the primary 
reference to the attachment, I'd like to unify things so that secondary 
references work the same way.

Marc.

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