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

Hi Noah,

I've read this thorough and I don't think these positions are irreconcilable
in many respects I think they are almost indistinguishable - but we're not
there yet (IMO).

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 03 April 2002 17:57
> To: Marc Hadley
> Cc: 'Christopher Ferris'; Williams, Stuart; xml-dist-app@w3.org;
> xml-dist-app-request@w3.org
> Subject: 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-

s/-or-/-and-/

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

Anything else is too broad. The idea/assumption in the previous formulation
was that different content-types could be used to distinguish different
attachment serialisation strategies. It was not intended that there be a
free-for-all, but that there be separate specifications for those strategies
and that the default binding specification be capable of leveraging any of
those well-defined strategies.

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

No... or at least this doesn't feel complete, seems to switch ends in the
middle.

Certainly, a requesting node is potentially shooting in the dark with
respect to the responding node, but it can potentially learn from experience
or form out of band information (which is no different from the conneg
feature proposal expect that it doesn't go so far as exposing conneg to the
SOAP node). As currently drafted a responding node may responds with an http
status code of 415 (Unsupported media) which is interpreted as indicating
the responding node does not support the attachment serialisation strategy
adopted by the requesting node and the appropriate property in the MEC is
set to reflect the failure reason (the binding could go through it's entire
repetoire of packaging strategies to find one that works - or not). 

An Accept: header on the outbound request message, subject to the assumption
that attachment strategies can be distinguished by content-type, can
indicate to the responder the packaging strategies supported by the sender -
at this point of course it is not know whether the response will infact need
to contain any attachments. The binding at the responder *could* provide a
property in the MEC that indicated whether response attachments could be
supported in this case, and in the event that they can't the responder would
have to restrict its behaviour. 

This is no different with a SwA/HTTP binding interoperating with a
SOAP/DIME/HTTP binding.


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

But you could make such a substitution if you were to regard them as
different bindings with different names and you still wouldn't get any
improvement in interoperability. You would be able to say that each binding
conforms to a different binding specification, hence the indiviudual
conformance tests are different, but I don't see interop being improved
here. At best, there is perhaps more clarity about the expectation of
non-interoperability.

 
> 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

And never anything else.

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

Ok... but this is largely undeserving of the definition of a conneg feature
(IMO) none of this need be exposed to the SOAP node (the thing using the
binding).

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

You could certainly do that - but you still face the *same* issues when
trying to use it with a non-DIME peer binding. We have only changed its
name, we have not solved any real problem. No improvement in interop. Only
set appropriately low expectation of interop.

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

Yes... and I don't see that as different from what was previously proposed.

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

The things that I think we are naming are binding specifications and not
their instantiations. An instantiation of a binding might support
capabilities defined in multiple specifications. I think I still favor a
world in which we name the modular pieces and we have binding instantiations
that enumerate what modular pieces they implement (at least to the local
SOAP node). I'm not sure that its tractable or necessary to create a
specification SOAP over DIME over HTTP and a different one for SOAP over
MIME over HTTP and a different one still for SOAP over (DIME or MIME) over
HTTP and so-on.

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

Basically, I don't see there being a hugh difference in the interop
characteristics of the two positions we've been discussing.

regards

Stuart

Received on Wednesday, 3 April 2002 13:20:18 UTC