Re: Proposed resolution for issue 440

On 8 Nov 2003, at 08:54, Martin Gudgin wrote:
>>
>>>> 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.
>
Are you suggesting that all representation headers should be targeted 
at 'none' then ?

>> 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.
>
But making the mapping 1:1 introduces its own set of problems when you 
want to reference the same data in multiple places.

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

>>>
>>> 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.
>
That's kind of an extreme position.

>>>>
>>>> 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?
>
And your application then needs to know all about the optimization 
mechanism in order to be able to sign stuff properly. The beauty of 
MTOM is that its transparent to apps.

>> 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.
>
By primary reference I mean the Include as currently conceived.

Marc.

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