ODATA-1610

docs/odata-protocol/odata-protocol.html

@@ -1010,7 +1010,7 @@ <h4 id="8287-preference-returnrepresentation-and-returnminimal"><a name="Prefere
 <h4 id="8288-preference-respond-async"><a name="Preferencerespondasync" href="#Preferencerespondasync">8.2.8.8 Preference <code>respond-async</code></a></h4>
 </summary>
 <p>The <code>respond-async</code> preference, as defined in <a href="#rfc7240">RFC7240</a>, allows clients to request that the service process the request asynchronously.</p>
-<p>If the client has specified<code> respond-async</code> in the request, the service MAY process the request asynchronously and return a <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> response.</p>
+<p>If the client has specified<code> respond-async</code> in the request, the service MAY process the request <a href="#AsynchronousRequests">asynchronously</a> and return a <a href="#ResponseCode202Accepted"><code>202 Accepted</code></a> response.</p>
 <p>The <code>respond-async</code> preference MAY be used for batch requests, in which case it applies to the batch request as a whole and not to individual requests within the batch request.</p>
 <p>In the case that the service applies the <code>respond-async</code> preference it MUST include a <a href="#HeaderPreferenceApplied"><code>Preference-Applied</code></a> response header containing the <code>respond-async</code> preference.</p>
 <p>A service MAY specify the support for the <code>respond-async</code> preference using an annotation with term <a href="https://github.com/oasis-tcs/odata-vocabularies/blob/main/vocabularies/Org.OData.Capabilities.V1.md#AsynchronousRequestsSupported"><code>Capabilities.AsynchronousRequestsSupported</code></a>, see <a href="#ODataVocCap">OData-VocCap</a>.</p>
@@ -2836,6 +2836,11 @@ <h2 id="116-asynchronous-requests"><a name="AsynchronousRequests" href="#Asynchr
 <p>Responses that return <code>202 Accepted</code> MUST include a <a href="#HeaderLocation"><code>Location</code></a> header pointing to a <em>status monitor resource</em> that represents the current state of the asynchronous processing in addition to an optional <a href="#HeaderRetryAfter"><code>Retry-After</code></a> header indicating the time, in seconds, the client should wait before querying the service for status. Services MAY include a response body, for example, to provide additional status information.</p>
 <p>A <code>GET</code> request to the status monitor resource again returns <code>202 Accepted</code> response if the asynchronous processing has not finished. This response MUST again include a <a href="#HeaderLocation"><code>Location</code></a> header and MAY include a <a href="#HeaderRetryAfter"><code>Retry-After</code></a> header to be used for a subsequent request. The <code>Location</code> header and optional <code>Retry-After</code> header may or may not contain the same values as returned by the previous request.</p>
 <p>A <code>GET</code> request to the status monitor resource returns <a href="#ResponseCode200OK"><code>200 OK</code></a> once the asynchronous processing has completed. For OData 4.01 or greater responses, or OData 4.0 requests that include an <code>Accept</code> header that does not specify <code>application/http</code>, the response MUST include the <a href="#HeaderAsyncResult"><code>AsyncResult</code></a> response header. Any other headers, along with the response body, represent the result of the completed asynchronous operation. If the <code>GET</code> request to the status monitor includes an <code>OData-MaxVersion</code> header with a value of <code>4.0</code> and no <code>Accept</code> header, or an <code>Accept</code> header that includes <code>application/http</code>, then the body of the final <code>200 OK</code> response MUST be represented as an HTTP message, as described in <a href="#rfc9110">RFC9110</a>, which is the full HTTP response to the completed asynchronous operation.</p>
+<p>If a client queries the status monitor resource with a <a href="#Preferencewait"><code>wait</code></a> preference, the preference applies to the status query and not to the original request that is processed asynchronously. A server may</p>
+<ul>
+<li>ignore the <code>wait</code> preference on a status query, or</li>
+<li>respond with <code>202 Accepted</code> to indicate that asynchronous processing of the original request is probably still ongoing if it cannot finish the status query within the given length of time.</li>
+</ul>
 <p>A <code>DELETE</code> request sent to the status monitor resource requests that the asynchronous processing be canceled. A <code>200 OK</code> or a <a href="#ResponseCode204NoContent"><code>204 No Content</code></a> response indicates that the asynchronous processing has been successfully canceled. A client can request that the <code>DELETE</code> should be executed asynchronously. A <code>202 Accepted</code> response indicates that the cancellation is being processed asynchronously; the client can use the returned <a href="#HeaderLocation"><code>Location</code></a> header (which MUST be different from the status monitor resource of the initial request) to query for the status of the cancellation. If a delete request is not supported by the service, the service returns <a href="#ResponseCode405MethodNotAllowed"><code>405 Method Not Allowed</code></a>.</p>
 <p>After a successful <code>DELETE</code> request against the status monitor resource, any subsequent <code>GET</code> requests for the same status monitor resource returns <a href="#ResponseCode404NotFound"><code>404 Not Found</code></a>.</p>
 <p>If an asynchronous request is cancelled for reasons other than the consumers issuing a <code>DELETE</code> request against the status monitor resource, a <code>GET</code> request to the status monitor resource returns <code>200 OK</code> with a response body containing a single HTTP response with a status code in the <a href="#ServerErrorResponses"><code>5xx Server Error</code></a> range indicating that the operation was cancelled.</p>

docs/odata-protocol/odata-protocol.md

@@ -1553,7 +1553,7 @@ allows clients to request that the service process the request
 asynchronously.
 
 If the client has specified` respond-async` in the request, the service
-MAY process the request asynchronously and return a
+MAY process the request [asynchronously](#AsynchronousRequests) and return a
 [`202 Accepted`](#ResponseCode202Accepted) response.
 
 The `respond-async` preference MAY be used for batch requests, in which
@@ -5683,6 +5683,11 @@ then the body of the final `200 OK` response MUST be represented as an
 HTTP message, as described in [RFC9110](#rfc9110), which is the full
 HTTP response to the completed asynchronous operation.
 
+If a client queries the status monitor resource with a [`wait`](#Preferencewait) preference, the preference applies to the status query and not to the original request that is processed asynchronously.
+A server may
+- ignore the `wait` preference on a status query, or
+- respond with `202 Accepted` to indicate that asynchronous processing of the original request is probably still ongoing if it cannot finish the status query within the given length of time.
+
 A `DELETE` request sent to the status monitor resource requests that the
 asynchronous processing be canceled. A `200 OK` or a
 [`204 No Content`](#ResponseCode204NoContent) response indicates that the asynchronous processing has

odata-protocol/11.5 Operations.md

@@ -518,6 +518,12 @@ then the body of the final `200 OK` response MUST be represented as an
 HTTP message, as described in [RFC9110](#rfc9110), which is the full
 HTTP response to the completed asynchronous operation.
 
+If a client queries the status monitor resource with a [`wait`](#Preferencewait) preference, 
+the preference applies to the status query and not to the original request that is processed asynchronously.
+A server may
+- ignore the `wait` preference on a status query, or
+- respond with `202 Accepted` to indicate that asynchronous processing of the original request is probably still ongoing if it cannot finish the status query within the given length of time.
+
 A `DELETE` request sent to the status monitor resource requests that the
 asynchronous processing be canceled. A `200 OK` or a
 [`204 No Content`](#ResponseCode204NoContent) response indicates that the asynchronous processing has

odata-protocol/8 Header Fields.md

@@ -664,7 +664,7 @@ allows clients to request that the service process the request
 asynchronously.
 
 If the client has specified` respond-async` in the request, the service
-MAY process the request asynchronously and return a
+MAY process the request [asynchronously](#AsynchronousRequests) and return a
 [`202 Accepted`](#ResponseCode202Accepted) response.
 
 The `respond-async` preference MAY be used for batch requests, in which