Re: Suggestion on application/soap{+xml} media type attribute

+1

Henrik Frystyk Nielsen wrote:

> While changing the MIME media type for SOAP messages to either
> "application/soap+xml" or "application/soap", here is something that we
> might consider in moving forward regardless of which direction we take.
> 
> As discussed at length on various mailing lists, the main purpose of the
> SOAPAction header field is to indicate the *type* of the SOAP message
> using a URI rather than a centrally registered mechanism such as a media
> type. This was expressed in a fluffy way as "intent".
> 
> The reason for this is to enable MIME/RFC 822-based applications to be
> able to get an OPTIONAL hint about what the SOAP message contains
> without having to parse the SOAP message. As hints go, this is useful in
> the same way the MIME content type is useful.
> 
> The reason for introducing SOAPAction header field was to avoid many of
> the apparent problems in mixing media type formats with URIs in general.
> One reason for this was that the media type for XML was "text/xml" with
> only one attribute (charset).
> 
> As we are now defining a new media type, we no longer have this
> constraint. Therefore, I suggest we consider defining an OPTIONAL media
> type attribute as part of our new media type that can contain this
> information, something like this:
> 
> 	application/soap+xml; action="http://www.example.org/foo"
> 
> If we go this way we can in fact GET RID OF SOAPAction HTTP header field
> altogether and make the link between the media type explicit hence
> avoiding some of the confusion.
> 
> Note that it is NOT the purpose of this mail to bring up the discussion
> of whether the information can be trusted, used for dispatch, carried in
> the SOAP message itself, or anything else - it is STRICTLY a suggestion
> for defining a SOAP media type attribute. The defining text will of
> course take into account security concerns as any media type has to do.
> 
> Comments?
> 
> Henrik Frystyk Nielsen 
> mailto:henrikn@microsoft.com 
> 
>

Received on Monday, 3 December 2001 11:03:31 UTC