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

Re: ROR proposal issue #1 (aka SC1)

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 4 Apr 2006 16:50:30 -0400
To: "Mark Baker" <distobj@acm.org>
Cc: "michael.mahan@nokia.com" <michael.mahan@nokia.com>, xml-dist-app@w3.org
Message-ID: <OF76F7C13E.524CDAE5-ON85257146.0051061A-85257146.00727D56@lotus.com>

Mark Baker writes:

> Issue: Think it's perfectly fine if a SOAP response is returned
> on a 202 response. What's most important to indicate, I believe,
> is that because of the semantics of 202, that any SOAP envelope
> would not represent the results of processing the inbound SOAP
> message.  It only indicates an intermediate result, like an ack.

I'm a little surprised by how you phrased this.  I think we're agreed that 
a 202 certainly indicates that the response does not denote >completion< 
of processing of the request, and indeed in general a 202 is by reading 
silent as to whether any processing has been started or attempted.  So far 
so good.  What surprises me is that your text can be read as insisting 
that any response have nothing to do with the message in question, and I 
don't read the HTTP RFC that way.  My impression is that any ack or the 
like should specifically be in relation to the request received. Do you 
agree?

I believe that in this respect, the reliable messaging folks would be 
stretching HTTP of an RM-related 202+envelope were sent as a response to a 
request that contained no RM header.  As someone (Chris?) observed last 
week, most requests in this scenario do contain an RM header, so it's at 
least plausible to suggest that any RM-related response was at least in 
some sense solicited, and is thus OK.  What are your thoughts on this? 
Thanks.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Tuesday, 4 April 2006 20:50:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC