Re: SOAP MIME Type

I am in agreement with this suggestion. I did discuss with a Liberty 
member the idea of defining a new media type, that basically extended 
text/xml and added an optional namespace parameter. But that wouldn't 
get us out of "IANA hell" (which I would fully support given Liberty's 
previous media type registration, which took several months to get 
approved).

I also liked Don's suggestion of providing a syntax for adding the 
Qname in addition to the NS, but I don't know that it is necessary.

So, what's the next step?

- JohnK

On Thursday, May 8, 2003, at 21:58 US/Eastern, Don Box wrote:

> +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
>>>>
>>>>
>>>
>>>
>
>
________________________________
John Kemp / john.kemp@ieee-isto.org
(+1) 413.458.9053    /    frumioj@AOL
Coordinating Editor   /   Project Liberty