Re: [TBTF] proposed edits for incorporating conneg feature for HT TP binding

Mark Hadley writes:

>> +1, mandating use of application/soap+xml as the only 
>> supported encoding prevents use of, e.g SOAP+attachements, 
>> with this binding. I brought this up on the latest TBTF call. 
>> I would prefer a more flexible approach where other content 
>> types may also be used with the content negotiation feature 
>> being used to reach agreement on a mutually supported encoding.

Let me explain the other point of view, that led to the current proposal.

In rough outline, I think you're proposing that our binding say:  "To 
conform to the (W3C-supplied) SOAP HTTP binding  you must

* Always be capable of accepting application/soap+xml.  If you choose to 
send application/soap+xml, you must use it in the manner described. 
-or-
* You can send or receive anything else you like, as long as you use a 
different media type.
* However, if you are a responder, and you get a conneg requesting 
application/soap+xml, you SHOULD respond with that. In all
other cases, you can send what you like (since conneg doesn't help with 
POST, I think, only with RESPONSE. Right?)"

The problem I have with this is that stating that you conform to this 
binding doesn't buy you much interoperability.  It means that I might have 
two sites, both of which successfully communicate using conforming 
implementations of the binding. If I look under the covers I find that 
they are always using SOAP+Attachments or DIME, and have indeed been 
exchanging attachments.  I now substitute a different vendor's 
implementation at one end of the connection, and it too is conforming to 
the binding.  Still, the originator insists on POSTing with its own MIME 
type, both ends are conforming, and there's no interop.

The reason I prefer the other approach is that I think it says more 
clearly what's going on.  It provides much better control over 
interoperability and conformance.  In that approach, "To conform to the 
(W3C-supplied) SOAP HTTP binding  you must:

* Always send and receive application/soap+xml
* If you want to be helpful to others, support sending and accepting 
conneg headers.  Since this binding only supports one media type, you 
always indicate that when sending a conneg header, and you only respond 
successfully of application/soap+xml is requested."

So, how do you make something like DIME work?  As you have pointed out, 
most of the marketplace wants attachments, and I believe we should get 
there as soon as possible.  To make DIME work, you would publish a 
specification for a new binding, call it DIME over HTTP.  That 
specification would indicate the ways in which it could interoperate with 
nodes supporting only our binding.  For example, it would supply conneg 
headers indicating that it supported both the application/soap+xml and 
application/???dime?? media types, in situations where attachments were 
not expected.  It would, perhaps, default to sending appliation/soap+xml 
in any situation in which there was, in fact, no attachment.

With the approach I am advocating, you have the situation in which saying 
"I support the soap HTTP binding" or "I support the soap DIME binding, but 
by the way interoperate with the soap HTTP binding" means something.  Each 
has an appropriately tight statement of conformance, and you get all the 
interoperability you want.  Furthermore, if someone then goes and builds a 
binding to SOAP+Attachments, or even builds a binding that adapts among 
all three, you can give that binding a name, and a clear specification 
with appropriate conformance requirements.  You can clearly see which 
combinations will interoperate and which will not.  I think we lose that 
if our own binding allows an open-ended set of conventions to be 
conforming.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Marc Hadley <marc.hadley@sun.com>
Sent by: xml-dist-app-request@w3.org
04/03/2002 08:52 AM

 
        To:     "Williams, Stuart" <skw@hplb.hpl.hp.com>
        cc:     "'Christopher Ferris'" <chris.ferris@sun.com>, xml-dist-app@w3.org, (bcc: 
Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: [TBTF] proposed edits for incorporating conneg feature for HT       TP 
binding


Williams, Stuart wrote:

> 
> I have a number of concerns with the direction that this is now going. 
> 
> 1) The original motivation for the discussion, as I recall, was directed 
at
> the resolution of Issue #61 [1]. I think what is proposed in [2] is
> no-longer focussed on that, indeed as far as I can tell it defines a 
binding
> that is (possibly deliberately) incapable of supporting *any* attachment
> scheme.
> 

+1, mandating use of application/soap+xml as the only supported encoding 
prevents use of, e.g SOAP+attachements, with this binding. I brought 
this up on the latest TBTF call. I would prefer a more flexible approach 
  where other content types may also be used with the content 
negotiation feature being used to reach agreement on a mutually 
supported encoding.


Pretty much every SOAP implementation supports attachments. If we go with 
the proposed formulation then an implementation that supports attachements 
cannot be said to conform to our binding, only perhaps to interoperate 
with it.


Regards,

Marc.



-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Wednesday, 3 April 2002 12:20:01 UTC