Re: SOAP MIME Type

John,

I very much sympathize with your problem; you've encountered a fairly
serious limitation of the use of media types by content negotiation, in
that their relationship to XML is cloudy at best. I'll go out on a limb
and say that I think that RFC3023 is fundamentally the wrong approach,
because it requires the authors of XML formats to register them centrally
(with IANA), even though the WHOLE IDEA behind XML and more specifically
SOAP is decentralized language creation.

From a SOAP perspective, your statements below are correct. However, in
the use of media types, it's necessary to take account of how media types
are used and what they are used for, rather than the constraints of the
SOAP processing model.

From that perspective, a media type HAS to identify a single format, or at
most a group of formats that share compatibility. SOAP 1.1 and SOAP 1.2,
despite their common names, are not compatible by any stretch of the
imagination. If a HTTP client sends "Accept: application/soap+xml" and
receives a SOAP 1.2 message, that is an error from not only SOAP's, but
more importantly HTTP's standpoint, because the client isn't able to
consume it.

It is difficult to register a media type for SOAP 1.1 ex post facto
whether it's application/soap+xml or something else, because SOAP 1.1
says:
   HTTP applications MUST use the media type "text/xml" according to RFC
2376 [3] when including SOAP entity bodies in HTTP messages.
AFAIK it would be very difficult to get a media type registration through
that breaks the requirements of one of the protocols it refers to.

I'd suggest that there are two other paths to a solution for your problem:
  1) using "Accept: text/xml, application/soap+xml" and having a private
agreement that the text/xml dialect that you expect is SOAP1.1
  2) defining a new negotiation mechanism that uses URIs rather than media
types. It could very often be used with namespaces, but I suspect the
semantic is more similar to SOAPAction, in that it isn't necessarily a
namespace, but rather an identifier for the format itself. E.g.,

GET /foo HTTP.1.1
Accept: text/xml, application/soap+xml
Accept-XML-Dialect: "http://schemas.xmlsoap.org/soap/envelope/"
...

HTTP/1.1 200 OK
Content-Type: text/xml
XML-Dialect: "http://schemas.xmlsoap.org/soap/envelope/"
Vary: Content-Type, XML-Dialect

In other words, make that private agreement public and explicit. I would
be VERY happy to help specify this mechanism, as I think it solves a
problem that's going to affect a lot more people than just you.

Cheers,



----- Original Message ----- 
From: "John Kemp" <john.kemp@earthlink.net>
To: "Mark Baker" <distobj@acm.org>
Cc: <xml-dist-app@w3.org>
Sent: Thursday, May 08, 2003 1:18 PM
Subject: 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
> >
> >
>
>

Received on Thursday, 8 May 2003 17:01:50 UTC