Re: Binding example discussion

Mark Baker wrote:
<snip/>
> 
> But the response body of a 202 is supposed to be an indication of the status of the response.  It's true that this status
> information is correlated with the SOAP request, but it need not (and should not, IMO, per my other email) be a SOAP
> response.

Here I'd have to disagree. An acknowledgment could take the form of a SOAP message. It just
isn't the ultimate response.

> 
> >> how an
> >> application can determine correlation when the response is returned through some other means?  At a minimum I
> think
> >> we should say that other mechanisms can be used on top of SOAP (say, a transaction header block), but that the
> >> HTTP binding does not define such a mechanism.
> >
> >Agreed. However, in the case of SOAP-RPC, or more precisely, the request/response
> >MEP, the binding specification would need to say something to the effect that
> >a 202 Accepted status code MUST NOT be returned.
> 
> Why couldn't an RPC use return 202?  RPC is a bit of a free-for-all architecturally, so if some app wanted to implement
> these "detachment semantics" itself, or reuse that feature of HTTP, shouldn't it have the option?
> 
Unless all SOAP RPC clients were designed to accomodate this free-for-all,
then there would be some serious interop problems! By what convention does the
client obtain the response if it receives a 202 response? SHALL the 202 response
carry a canonical mechanism (or reference by means of an URI) to obtain
the response? If this is the case, then that needs to be clearly spelled out.

> Not that I care much about RPC. 8-)  Just curious.

Me neither;-)

> 
> >I could conceive of use of the 202 Accepted status response for one-way message
> >exchanges, to infer that the message has been received, but not processed and
> >a 204 No Content status response as meaning received AND processed.
> 
> ... and has no response to provide.  Agreed.
> 
> MB

Received on Wednesday, 18 July 2001 16:06:34 UTC