RE: SOAP MIME Type

+1 to mark's suggestion.  See
http://www.gotdotnet.com/team/dbox/default.aspx#nn2003-05-09T01:56:00Z


DB


> -----Original Message-----
> From: Mark Nottingham [mailto:mark.nottingham@bea.com]
> Sent: Thursday, May 08, 2003 2:01 PM
> To: Mark Baker; John Kemp
> Cc: xml-dist-app@w3.org
> 
> 
> 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 21:58:48 UTC