W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

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

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Wed, 24 Apr 2002 15:42:39 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192B10@0-mail-1.hpl.hp.com>
To: "'Mark Baker'" <distobj@acm.org>, Christopher Ferris <chris.ferris@sun.com>
Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, noah_mendelsohn@us.ibm.com, henrikn@microsoft.com, john_ibbotson@uk.ibm.com, marc.hadley@uk.sun.com, martin.gudgin@btconnect.com, moreau@crf.canon.fr, xml-dist-app@w3.org
Hi Mark,


> On Wed, Apr 24, 2002 at 07:47:58AM -0400, Christopher Ferris wrote:
> > Maybe it just needs to be clearer as to the nature of the
> > entity body that MAY appear in the 202 response. It MAY
> > be a SOAP message detailing for the requester when it might
> > expect the result to be ready. It MAY be an acknowledgment
> > message such as might be used for reliable messaging
> > for purposes of nonrepudiation such as defined by ebXML.
> 
> I agree.  It might also not be a SOAP response.

:-)

> > I would suggest that it NOT be removed just clarified.
> 
> 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.

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

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

> I apologize to Stuart for not catching this earlier, but I wouldn't have
> caught it at all if not for Noah's message that prompted me to check how
> the binding handles 202.
> 
> 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 10:44:17 GMT

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