Re: Representation header

Is there an expectation that putting headers in Representation will 
also secure the MIME part's headers on the wire when xbinc:Include is 
used?

I don't see a use case for doing so, as long as we're working in the 
context of a MIME envelope. If we allow xbinc:Include to reference 
arbitrary resources from the Web, it may become necessary.

I do see a case for securing the binding's top-level metadata (in HTTP, 
the HTTP headers), but that's a separate topic IMO.


On Nov 5, 2003, at 7:12 AM, [email protected] wrote:

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