Re: Providing a short name for single-request-response MEP

Hi Stuart,

On Wed, Apr 24, 2002 at 03:42:39PM +0100, Williams, Stuart wrote:
> > The problem with not removing it is that there are certain assumptions
> > made by the MEP and HTTP binding with respect to the SOAP processing
> > model.  The big one is that if you get a response, that it is a result
> > of the SOAP Envelope being processed.
> 
> I'm not sure that I really buy that... I think that the assumption that the
> MEP and HTTP binding make is that the response message is causally dependent
> on the request message - certainly, I think that's the only assumption I'd
> be comfortable with.

That's good to hear, but consider;

"The normal operation of a message exchange conforming to the single-request-response exchange pattern is such that a Request Message is first transferred from Requesting SOAP Node to Responding SOAP Node. Following the successful processing of the Request Message by the Responding SOAP Node, a Response Message is then transferred from Responding SOAP Node to Requesting SOAP Node."
 -- http://www.w3.org/2000/xp/Group/2/04/11/soap12-part2-1.55.html#bindinfdesc

This says that the MEP follows a request/process/response model, where
I can only assume that "process" means what we define in Part 1 Sec 2.6.
The formal description appears to say the same thing with its use of
the word "process" in the description of the 2xx response codes.

If we mean something different by "process" here than what is described
in 2.6, we've got some re-editing to do.

> > So in order to be able to support
> > a 202 response in this binding, we'd have to create a MEP that exposed
> > the difference between a response that implies the SOAP processing model
> > was obeyed, and another type of response which implies that 
> > it was not.
> 
> So I think what was in my mind when drafting table 11 was the philosophy
> about classes of status codes, from RFC 2616 section 6.1.1:
> 
>    HTTP status codes are extensible. HTTP applications are not required
>    to understand the meaning of all registered status codes, though such
>    understanding is obviously desirable. However, applications MUST
>    understand the class of any status code, as indicated by the first
>    digit, and treat any unrecognized response as being equivalent to the
>    x00 status code of that class, with the exception that an
>    unrecognized response MUST NOT be cached.
> 
> which might allow me to exhibit a degree of ignorance about the specific
> meaning of 202 and treat it "as being equivalent to x00 (200 in this case)."

Absolutely.  But from section 10.2 of RFC 2616 regarding 2xx response
codes;

"This class of status code indicates that the client's request was
successfully received, understood, and accepted."

i.e. *not* processed.  If you receive a response code that starts with a
"2", you cannot assume that the message was processed.

This is related to the issue I identified here;

http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0205

> > I hope you agree that it's a bit late for that! 8-)
> 
> I don't think I would want to develop MEPs with 'minor' differences. I think
> that there is scope (and possibly time) to add a property that account for
> the disposition of the exchange eg. processing complete, pending, faulted...
> . Might be a more generic form of context:FailureReason, which elaborates
> exchanges that fail - instead, or aswell as, something that elaborates on
> degrees of success.

Do you still believe so?

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Wednesday, 24 April 2002 12:10:12 UTC