RE: Representation header

Martin Gudgin writes:

> One reason for specifying information in the
> Representation header is that it can be secured using
> the mechanisms in WS-Security as it's just another
> piece of XML.

Agreed.  I think it's very important to keep the levels straight. 

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.

It is also true that our preferred serialization and the proposed HTTP 
binding that use it are MIME based, giving us the opportunity to carry 
some of the same information in the "on the wire" MIME container.  That is 
a completely different level that applies only to bindings that use that 
particular serialization. I can see both sides to the question of whether 
our serialization should explicitly carry indications such as 
Content-Type="image/jpeg".  That's redundant information available from 
the attribute in the Infoset (if available at all).  Getting it into the 
MIME envelope will require some tracking of the state of the XML, and 
perhaps some XML parsing.  The serializer now needs to know not only that 
content is base64 canonical but also the values of attributes surrounding 
it.  On the other hand, it clearly is a better use of MIME to explicitly 
indicate the content-type if known than to just label everything as an 
OctetStream.  So, I'm curious what others think on this question.

In any case, I am not comfortable with a design that presumes that all 
MTOM implementations use the preferred serialization, and that infer MIME 
type information from it.  Indeed, we've been very clear that MTOM content 
should travel with full fidelity over the SOAP 1.2 HTTP binding. 

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. 

Thank you!

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 5 November 2003 10:13:25 UTC