Re: SOAP MIME Type

OK,

So I think I'm hearing that the media type application/soap+xml is 
intended to be used with multiple versions of the SOAP envelope, 
provided said versions are considered backwards-compatible with SOAP 
1.2 envelope - which presumably is determined using the namespace URI 
supplied in the SOAP envelope.

What does that mean for its use with SOAP 1.1 envelopes? Right now, I 
don't think there are any processing rules that depend on use of the 
media type. I note that the 'action' parameter is optional, which does 
not preclude SOAP 1.1. A SOAP 1.2 processor will fault a received 1.1 
message according to [SOAP121] 2.8, regardless of the media type. So no 
1.2-specific processing will take place as a result of receiving a SOAP 
1.1 envelope + application/soap+xml being received.

So, I guess I don't really see why you couldn't just say somewhere that 
the media type would indicate merely use of XML-serialized SOAP 
messages. You have defined compatibility rules based on the namespace, 
not on the media type. I don't see anything anywhere that says a SOAP 
processor MAY/MUST/SHOULD use the application/soap+xml media type to 
determine that a sender supports a version of SOAP > 1.1, but I DO see 
rules that say if the namespace URI indicates version < 1.2 a fault 
should be returned.

By not saying anything in the registration, or providing any processing 
rules, it appears that you are basically not disallowing the use of 
this media type with SOAP 1.1 envelopes - and I read

<excerpt doc="draft-baker-soap-media-reg-02.txt">
"This specification defines the media type "application/soap+xml"
    which can be used to identify SOAP messages serialized with XML 1.0
    carried in MIME or MIME like protocols that support the concept of
    media types for which a SOAP binding has been defined."
</excerpt>

to mean ANY SOAP message, not just >= 1.2. It's just the surrounding 
text (introduction and abstract) that refer to SOAP 1.2, and then the 
registration form itself being located in [SOAP122]

Our spec says:

> Conforming applications of this binding:
> 1. MUST be capable of sending and receiving messages serialized using 
> media type "application/soap+xml" whose 97
> proper use and parameters are described in "The application/soap+xml 
> Media Type". 98
> 2.MAY, when sending requests, provide an HTTP Accept header field. 
> This header field 99
> 100
> a. SHOULD indicate an ability to accept at minimum 
> "application/soap+xml" 101
> b.MAY additionally indicate willingness to accept other media types 102

So, what I really like is the following:

1) That the registration for the MIME removes the '1.2' from the 
abstract and introduction sections.
2) It would be nice if the media type registration form were decoupled 
from the SOAP 1.2 spec :)
3) We would note that although the media type is (partially) defined in 
the SOAP 1.2 specification, that its use in our PAOS binding at least 
is not specifically linked to a particular version of SOAP (and that we 
normatively refer to SOAP 1.1 in that spec.) We would then have an 
informative reference to the SOAP 1.2 specification (if you didn't 
decouple the registration form).
4) It could be defined on a binding level whether or not the media type 
may or may not be used for anything in particular. As nothing is 
defined at the protocol level, that seems entirely reasonable.

It doesn't seem unreasonable to decouple the media type registration 
from SOAP 1.2 does it really? I certainly cannot see how it hurts 
interoperability as currently defined in SOAP 1.2 specifications.

BTW - I noticed that the reference you quote in the registration has a 
mismatched URL from the reference title:

> 4. References
>
> [SOAP12P2] "SOAP Version 1.2 Part 2: Adjuncts", W3C Candidate
>          Recommendation (work in progress), December 2002.  Gudgin, M.,
>          Hadley, M., Mendelsohn, N., Moreau, JJ., Nielsen, H.
>          <http://www.w3.org/TR/2002/CR-soap12-part1-20021219>.

You reference Part 2 in the title, but the URL points to Part 1....

- JohnK

________________________________
John Kemp / john.kemp@ieee-isto.org
(+1) 413.458.9053    /    frumioj@AOL
Coordinating Editor   /   Project Liberty

On Thursday, May 8, 2003, at 14:17 US/Eastern, Mark Baker wrote:

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