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

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

Cheers,

Chris
Williams, Stuart wrote:

> Hi Mark,
> 
> The question that table 11 poses is, in the event that the given status
> codes are returned, what is or should be their significance in the context
> of a SOAP message exchange. The 202 status code allows an entity body...
> which if present, if present, should signify (somehow) the status of the
> request (extract below).
> 
> On the whole I'd be ok about saying nothing about status code 202 *if* it
> were something that were never going to arise in a conforming
> implementation.
> 
> In the context of a SOAP message exchange, when should a 202 status code be
> generated (possibly never) and if generated how should it affect the
> completion of the message exchange - eg. should any accompanying entity be a
> SOAP message? should SOAP defined a content model for such a message, or is
> it application dependent or is it a form of fault?
> 
> The tables were first drafted in October last year... it's a pity the
> discussion they were intended to provoke is only just beginning to happen.
> 
> Regards
> 
> Stuart
> --
> 
> <rfc2616>
> 10.2.3 202 Accepted
> 
>    The request has been accepted for processing, but the processing has
>    not been completed.  The request might or might not eventually be
>    acted upon, as it might be disallowed when processing actually takes
>    place. There is no facility for re-sending a status code from an
>    asynchronous operation such as this.
> 
>    The 202 response is intentionally non-committal. Its purpose is to
>    allow a server to accept a request for some other process (perhaps a
>    batch-oriented process that is only run once per day) without
>    requiring that the user agent's connection to the server persist
>    until the process is completed. The entity returned with this
>    response SHOULD include an indication of the request's current status
>    and either a pointer to a status monitor or some estimate of when the
>    user can expect the request to be fulfilled.
> </rfc2616>
> 
>>-----Original Message-----
>>From: Mark Baker [mailto:distobj@acm.org]
>>Sent: 24 April 2002 03:44
>>To: noah_mendelsohn@us.ibm.com
>>Cc: Mark Baker; chris.ferris@sun.com; henrikn@microsoft.com;
>>john_ibbotson@uk.ibm.com; marc.hadley@uk.sun.com;
>>martin.gudgin@btconnect.com; moreau@crf.canon.fr; skw@hplb.hpl.hp.com;
>>xml-dist-app@w3.org
>>Subject: Re: Providing a short name for single-request-response MEP
>>
>>On Tue, Apr 23, 2002 at 09:37:18PM -0400, 
>>noah_mendelsohn@us.ibm.com wrote:
>>
>>>The SOAP MEP makes very clear that the SOAP response is
>>>just that, the response to SOAP processing.  I believe
>>>that our HTTP binding only handles the case where the
>>>response is returned reasonably promptly, on the
>>>still-open connection. 
>>>
>>Promptness isn't the issue, it's "when is a response a response" 8-).
>>
>>And actually, what the binding says is incorrect.
>>
>>http://www.w3.org/2000/xp/Group/2/04/11/soap12-part2-1.55.html
>>#http-reqbindwaitstate
>>
>>For a HTTP 202 response, it says;
>>
>>"The Request Message has been received and processed. The entity body
>>of the HTTP response MAY contain a Response Message."
>>
>>which is incorrect, because a 202 response indicates only that the
>>message has been accepted, not processed.  This means that the SOAP
>>processing model cannot be assumed to have kicked in, which breaks
>>the MEP in not nice ways.
>>
>>At this point in time, I suggest that the easiest way out would
>>probably be to remove any mention of the 202 code.
>>
>>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 07:49:18 UTC