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:


<excerpt>+1 to mark's suggestion.  See

http://www.gotdotnet.com/team/dbox/default.aspx#nn2003-05-09T01:56:00Z



DB



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

</excerpt>in

<excerpt>that their relationship to XML is cloudy at best. I'll go out
on a

</excerpt>limb

<excerpt>and say that I think that RFC3023 is fundamentally the wrong
approach,

because it requires the authors of XML formats to register them

</excerpt>centrally

<excerpt>(with IANA), even though the WHOLE IDEA behind XML and more

</excerpt>specifically

<excerpt>SOAP is decentralized language creation.


From a SOAP perspective, your statements below are correct. However,

</excerpt>in

<excerpt>the use of media types, it's necessary to take account of how
media

</excerpt>types

<excerpt>are used and what they are used for, rather than the
constraints of

</excerpt>the

<excerpt>SOAP processing model.


From that perspective, a media type HAS to identify a single format,

</excerpt>or at

<excerpt>most a group of formats that share compatibility. SOAP 1.1
and SOAP

</excerpt>1.2,

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

</excerpt>but

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

</excerpt>RFC

<excerpt>2376 [3] when including SOAP entity bodies in HTTP messages.

AFAIK it would be very difficult to get a media type registration

</excerpt>through

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

</excerpt>problem:

<excerpt>  1) using "Accept: text/xml, application/soap+xml" and
having a

</excerpt>private

<excerpt>agreement that the text/xml dialect that you expect is SOAP1.1

  2) defining a new negotiation mechanism that uses URIs rather than

</excerpt>media

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

</excerpt>would

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



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

</excerpt></excerpt>URI

<excerpt><excerpt>supplied in the SOAP envelope.


What does that mean for its use with SOAP 1.1 envelopes? Right now,

</excerpt></excerpt>I

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

</excerpt></excerpt>does

<excerpt><excerpt>not preclude SOAP 1.1. A SOAP 1.2 processor will
fault a received

</excerpt></excerpt>1.1

<excerpt><excerpt>message according to [SOAP121] 2.8, regardless of
the media type. So

</excerpt></excerpt>no

<excerpt><excerpt>1.2-specific processing will take place as a result
of receiving a

</excerpt></excerpt>SOAP

<excerpt><excerpt>1.1 envelope + application/soap+xml being received.


So, I guess I don't really see why you couldn't just say somewhere

</excerpt></excerpt>that

<excerpt><excerpt>the media type would indicate merely use of
XML-serialized SOAP

messages. You have defined compatibility rules based on the

</excerpt></excerpt>namespace,

<excerpt><excerpt>not on the media type. I don't see anything anywhere
that says a

</excerpt></excerpt>SOAP

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

</excerpt></excerpt>see

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

</excerpt></excerpt>processing

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

</excerpt></excerpt>1.0

<excerpt><excerpt>    carried in MIME or MIME like protocols that
support the concept

</excerpt></excerpt>of

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

</excerpt></excerpt>the

<excerpt><excerpt>registration form itself being located in [SOAP122]


Our spec says:


<excerpt>Conforming applications of this binding:

1. MUST be capable of sending and receiving messages serialized

</excerpt></excerpt></excerpt>using

<excerpt><excerpt><excerpt>media type "application/soap+xml" whose 97

proper use and parameters are described in "The

</excerpt></excerpt></excerpt>application/soap+xml

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

</excerpt></excerpt></excerpt>types

<excerpt>102

<excerpt>

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

</excerpt></excerpt>decoupled

<excerpt><excerpt>from the SOAP 1.2 spec :)

3) We would note that although the media type is (partially) defined

</excerpt></excerpt>in

<excerpt><excerpt>the SOAP 1.2 specification, that its use in our PAOS
binding at

</excerpt></excerpt>least

<excerpt><excerpt>is not specifically linked to a particular version
of SOAP (and that

</excerpt></excerpt>we

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

</excerpt></excerpt>type

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

</excerpt></excerpt>a

<excerpt><excerpt>mismatched URL from the reference title:


<excerpt>4. References


[SOAP12P2] "SOAP Version 1.2 Part 2: Adjuncts", W3C Candidate

         Recommendation (work in progress), December 2002.

</excerpt></excerpt></excerpt>Gudgin,

<excerpt>M.,

<excerpt><excerpt>         Hadley, M., Mendelsohn, N., Moreau, JJ.,
Nielsen, H.

         <<http://www.w3.org/TR/2002/CR-soap12-part1-20021219>.

</excerpt>

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:


<excerpt>

On Thu, May 08, 2003 at 01:17:25PM -0400, Paul Denning wrote:

<excerpt>

At 05:08 PM 2003-05-07, John Kemp wrote:

<excerpt>2) What is the strategy for future versions of SOAP - will

</excerpt></excerpt></excerpt></excerpt></excerpt>future

<excerpt><excerpt><excerpt><excerpt><excerpt>versions

use a new MIME type each time, or will they continue to use that

defined

in the SOAP 1.2 specification?

</excerpt>

Perhaps related is application/rss+xml, where a case is made to

</excerpt></excerpt></excerpt></excerpt>have

<excerpt><excerpt><excerpt><excerpt>this

media type apply to multiple versions of RSS [1].

</excerpt>

application/soap+xml supports multiple versions too.  Just not the

one John wants supported. 8-)


<excerpt>The IANA considerations section of [2] specifies an optional

parameter:


revision


       The optional revision parameter indicates the integer

</excerpt></excerpt></excerpt></excerpt>version

<excerpt><excerpt><excerpt><excerpt>of

       RSS used; the value is specified by the target RSS

</excerpt></excerpt></excerpt></excerpt>version.

<excerpt><excerpt><excerpt><excerpt>

SOAP 1.2 [3] definition of application/soap+xml does not define a

revision

parameter.

</excerpt>

Yes, in my experience those sorts of parameters are rarely, if

</excerpt></excerpt></excerpt>ever,

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

</excerpt></excerpt></excerpt>authored

<excerpt><excerpt><excerpt>it), but only because of a need that the
WAPforum had at the time

</excerpt></excerpt></excerpt>that

<excerpt><excerpt><excerpt>couldn't be met any other way due to an
incompatibility between

</excerpt></excerpt></excerpt>UAProf

<excerpt><excerpt><excerpt>and CC/PP (IIRC).  I haven't seen it used
either.


Even if we assigned such a parameter, I'd still recommend against

</excerpt></excerpt>using

<excerpt><excerpt>this media type with SOAP 1.1 envelopes, as it
needlessly

</excerpt></excerpt></excerpt>complicates

<excerpt><excerpt><excerpt>the job of a processor.  See RSS as an
example of compatibility

</excerpt></excerpt></excerpt>gone

<excerpt><excerpt><excerpt>wrong.  A (relatively) large barrier to
entry for aggregators has

</excerpt></excerpt></excerpt>been

<excerpt><excerpt><excerpt>created as it's expected that they must all
supports umpteen

</excerpt></excerpt></excerpt>versions

<excerpt><excerpt><excerpt>of

RSS (not to mention multiple media types! it's a mess).  Luckily

</excerpt></excerpt></excerpt>all

<excerpt><excerpt><excerpt>those versions are pretty simple, but you
could imagine how large

</excerpt></excerpt></excerpt>the

<excerpt><excerpt><excerpt>barrier could get for something like SOAP.


When compatibility is broken, register a new media type.  It's a

</excerpt></excerpt>pretty

<excerpt><excerpt>simple rule of thumb, and has served us very well in
the past.


MB

--

Mark Baker.   Ottawa, Ontario, CANADA.

</excerpt></excerpt></excerpt>http://www.markbaker.ca

<excerpt><excerpt><excerpt>Web architecture consulting, technical
reports, evaluation &

</excerpt></excerpt></excerpt>analysis

<excerpt><excerpt><excerpt>


</excerpt>


</excerpt></excerpt>


</excerpt>________________________________

John Kemp<fontfamily><param>Helvetica</param><bigger>
/</bigger></fontfamily> john.kemp@ieee-isto.org

(+1) 413.458.9053    /    frumioj@AOL

Coordinating Editor   /   Project Liberty