W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: Binding example discussion

From: Mark Baker <distobj@acm.org>
Date: Wed, 18 Jul 2001 15:44:14 -0400
Message-Id: <200107181944.PAA10562@mail3.magma.ca>
To: christopher ferris <chris.ferris@east.sun.com>
CC: Marc Hadley <marc.hadley@Sun.COM>, Mark Nottingham <mnot@akamai.com>, XML Distributed Applications List <xml-dist-app@w3.org>
Hi Chris,

7/18/2001 2:25:22 PM, christopher ferris <chris.ferris@east.sun.com> wrote:
>> If we say that both ends must infer correlation (which I think is what Mark's saying), then that's ok, right?
>
>That would suit me, but I don't think that's what Mark N was saying. The
>use of the term "may" in Mark N's description of correlation is quite
>incompatible with your "must".

Ok, sounds good.

>> There is one issue on this topic that may require some work on our part though; supporting an HTTP 203 (Accepted)
>
>I'm sure you meant 202 Accepted;-)

Oopsie!

>
>> response code.  Should a SOAP message be POSTed over HTTP and the server responds with a 203, the
>> correlation between request and response has now been broken.  Do we want/need to say anything about
>
>I'm not so certain that the correlation has been broken. If a 202 Accepted carried
>a SOAP envelope within the entity body of the response, it should be correlated
>with the request. It just isn't the ultimate response because Accepted means that
>the request message hasn't been processed by the application, just accepted by the server.

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.

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

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

>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 15:44:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT