RE: Representation header

On Wed, 5 Nov 2003 [email protected] wrote:

> To meet our use cases, MTOM needs to be more than an optimization
> mechanism:  it must provide means of carrying MIME-typed information in a
> SOAP Infoset, and optionally indicating that the content in question is a
> cached representation of some Web Resource.  That aspect of MTOM is, IMO,
> completely independent of the optimization, or of any particular
> embodiment of the optimization as binary in multipart MIME.

+1

> Yves Lafon writes:
>
> > All those metadata are transient and exists only
> > between two binding instances. If you sign it, then the
> > verification has to be done at the binding level and
> > not at the application level.
>
> With respect, I don't >think< so.   We are proposing attributes to go on
> content in the SOAP infoset.  Those attributes carry information about
> MIME types, and they represent a contract with (at least) whichever roles
> the headers target, or if in the body with the endpoint.  The fact that
> particular bindings may optimize on one hop or another is not the point, I
> think.

I shouldn't have used "All those metadata". I really meant that some
metadata are transient and invisible to the application when the message
is serialized (and, for example, sent to a mail server not 8-bit capable).

I fully agree that in most cases, the metadata are seen at the application
level and therefore should be in the SOAP infoset, this is the case when
we embed a "cached" version of a http URI.

(just sent that mail to clarify this to those not at the conf call)

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."