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

noah_mendelsohn@us.ibm.com wrote:

> Mark Hadley writes:
>

s/Mark/Marc/

 
> 
>>>+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. 

 >

Yes.


> -or-

'and', not 'or'


> * You can send or receive anything else you like, as long as you use a 
> different media type.

Yes.


> * 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?)"
> 

Close. If you are sending a POST (rather than responding to it) then you 
can send any MIME type you like. If you are responding to a POST then 
you should only send something that corresponds to whatever was in the 
POST's Accept header.

If you receive a POST request that uses a MIME type you don't support 
(e.g. DIME when you only support SOAP+Attachments) then you respond with 
a 415 status and list of the types you do support.


> 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."
> 

As I stated earlier, this would mean that every implementation that 
supports attachments (i.e. nearly all of them) could not be said to 
conform to our HTTP binding. We would be defining a set of conformance 
criteria that hardly anyone would be interested in conforming with !

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

I don't think this approach fixes the problem, let me play back your 
scenario from above but using the approach you are advocating:

I might have two sites, both of which successfully communicate using 
implementations that interoperate with our HTTP 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 interoperates with our HTTP binding.  Still, the originator insists 
on POSTing with its own MIME type, both ends claim interop with our 
binding, and there's no interop.

So, how do we fix the problem you raise. One way would be to define an 
in-envelope serialisation for attachments that all implementations must 
support. Using conneg, communicating implementations can drop back to 
this as a lowest common denominator when they can't agree on an 
alternative (and likely more efficient) way of serialising attachments. 
The other is to define a standard outside-the-envelope serialisation.

Regards,
Marc.


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

Received on Thursday, 4 April 2002 05:20:36 UTC