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

Noah,

Please see my comments below.

Cheers,

Chris

noah_mendelsohn@us.ibm.com wrote:

> 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 way I was thinking was that conneg *could* be used to build
a profile of the SOAP node at a given URI that could be remembered
for subsequent POSTs. It would be similar to the way that my mail
client remembers what the preferences are for recipients with
whom I've previously sent email. It doesn't have to do this, but
would be a useful optimization (IMO).


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


I'm not sure that I buy that argument. In thinking about the
evolution of the web, there is no mandated single media type.
HTTP doesn't say, "you MUST only send HTML4.x" and we've muddled
through. IMO, there will be a fairly limited set of media types
and it is likely that these will sink or swim on their merits.

IMO, this is no different than the case with extension headers
in the SOAP envelope with mU="true".


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


Again, the same argument could be made with SOAP header extensions.
If I substitute implementations, the extension may not be supported
and no interop! The more I think about this, the more I'm inclined
to disagree with this position.


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


Again, I'm not sure that I buy this argument any longer. I don't think
it is necessarily all that different than if we define how to achieve
interop by backing off to application/soap+xml as default that MUST
be supported as we have specified and by defining how conneg can
be used to discover feature capabilities (or lack thereof).


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

Received on Wednesday, 3 April 2002 12:48:50 UTC