Re: SOAP MIME Type

On Thu, May 08, 2003 at 01:17:25PM -0400, Paul Denning wrote:
> 
> At 05:08 PM 2003-05-07, John Kemp wrote:
> >2) What is the strategy for future versions of SOAP - will future versions 
> >use a new MIME type each time, or will they continue to use that defined 
> >in the SOAP 1.2 specification?
> 
> Perhaps related is application/rss+xml, where a case is made to have this 
> media type apply to multiple versions of RSS [1].

application/soap+xml supports multiple versions too.  Just not the
one John wants supported. 8-)

> The IANA considerations section of [2] specifies an optional parameter:
> 
> revision
> 
>        The optional revision parameter indicates the integer version of
>        RSS used; the value is specified by the target RSS version.
>
> SOAP 1.2 [3] definition of application/soap+xml does not define a revision 
> parameter.

Yes, in my experience those sorts of parameters are rarely, if ever,
used.  text/html used to have one, but it was removed in RFC 2854
because nobody used it.  application/xhtml+xml has one too (I authored
it), but only because of a need that the WAPforum had at the time that
couldn't be met any other way due to an incompatibility between UAProf
and CC/PP (IIRC).  I haven't seen it used either.

Even if we assigned such a parameter, I'd still recommend against using
this media type with SOAP 1.1 envelopes, as it needlessly complicates
the job of a processor.  See RSS as an example of compatibility gone
wrong.  A (relatively) large barrier to entry for aggregators has been
created as it's expected that they must all supports umpteen versions of
RSS (not to mention multiple media types! it's a mess).  Luckily all
those versions are pretty simple, but you could imagine how large the
barrier could get for something like SOAP.

When compatibility is broken, register a new media type.  It's a pretty
simple rule of thumb, and has served us very well in the past.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Thursday, 8 May 2003 14:15:41 UTC