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

Hi Mark,

> 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

Ok... too much attention to the tables on my part and reliance on
recollections of work done.

Maybe some editing required. Also, we are having a discussion in TBTF about
the potential a time overlap between requests and response which would also
call for this text to be revised.

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

:-) 

<snip/>

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

Ok... but this would appear to extend to 200 as well (depending on what is
mean't by success, which IIRC is defined (loosely) as the absense of an
(asserted) SOAP fault a response message).

10.2.1 200 OK

   The request has succeeded. The information returned with the response
   is dependent on the method used in the request, for example:

...

   POST   an entity describing or containing the result of the action;
...

> 
> This is related to the issue I identified here;
> 
> http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0205

Which is basically... what happens if I POST a SOAP message to an resource
that doesn't do SOAP?

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

Not sure quite what you are asking.... if it's do I still believe that there
is time to 'add a property' that works something like I described, then
yes... although I think the window of opportunity is a little narrow and
there would have to be some rapid concensus that it was the right thing to
do. If as a suggestion it has no appeal to you, then I suspect it would be a
futile gesture to try to go there. OTOH, if it looks like a direction that
would address your concern, it might be something we could do with enough
support and good will.

If you're asking something deeper, I think you might have to restate the
question.

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

regards

Stuart

Received on Wednesday, 24 April 2002 13:13:30 UTC