| Newsgroups |
gmane.text.xml.distributed |
| Message-ID |
<[email protected]> |
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
--------------------------------------