on the use of 202 or 204 in the ROR MEP

Here are the two different options there:

202
from rfc2616:
<<<
    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.
>>>

204
from rfc2616:
<<<
    The server has fulfilled the request but does not need to return an
    entity-body, and might want to return updated metainformation. The
    response MAY include new or updated metainformation in the form of
    entity-headers, which if present SHOULD be associated with the
    requested variant.
>>>

As ROR implies that there is a backchannel for errors (and it is not the 
case for a "pure" one-way MEP), it implies that a mustUnderstand fault 
should be sent back as an HTTP reply.

In that case, a 204 "No Content" signal the fact that the request has been 
processed, no errors were raised and there is no SOAP envelope to be sent.

It looks more in sync with what we want to achieve with ROR than using 202 
for that purpose.
Thanks,


-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Monday, 13 March 2006 11:03:51 UTC