Re: SOAP MIME Type

I think the next step is to put together an Internet-Draft (since it's
HTTP-related, the IETF is the most appropriate venue), and begin
discussion at both the W3C (TAG?) and in the IETF (http-wg list,
probably).

One important question that's bound to come up is whether to enable this
for just XML languages, or all formats; i.e., whether it's desirable to
come up with a URI-based typing system for the Web. My inclination is to
limit it to XML; although the registration process for media types can be
onerous (and there are signs that it's improving, BTW), it does serve a
purpose. I don't think the community would be served well by an explosion
of formats if there weren't a common thread (such as XML) that runs
through them.

Another issue is that which Don brings up; how to identify a specific
format. My inclination is to only use a URI, as URIs are first-class
identifiers on the Web, and anything worth identifying should have a URI.
That having been said, there's no regular way to turn a QName into a URI
[1], which I think is what Don wants to do. So, in the meantime, we could
do something like
 XML-Dialect: "http://example.com/foo.xsd"; localname="Bar"
making the localname parameter optional, so that we can drop it once the
QName mapping issue is solved to everyone's satisfaction.

This also has bearing on TAG issue 9 [2], and should be considered in that
context.

I'll endeavor to put together a first draft and circulate it ASAP.

Cheers,


1. http://www.w3.org/2001/tag/ilist#rdfmsQnameUriMapping-6
2. http://www.w3.org/2001/tag/ilist#uriMediaType-9


----- Original Message ----- 
From: "John Kemp" <john.kemp@earthlink.net>
To: "Don Box" <dbox@microsoft.com>
Cc: "Mark Nottingham" <mark.nottingham@bea.com>; "Mark Baker"
<distobj@acm.org>; <xml-dist-app@w3.org>
Sent: Thursday, May 08, 2003 8:23 PM
Subject: 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
>
>

Received on Friday, 9 May 2003 22:27:24 UTC