Original text:
If a "wait" parameter was included in the response-continue, the client instance MUST NOT call the continuation URI prior to waiting the number of seconds indicated.  If no "wait" period is indicated, <del> the client instance SHOULD wait at least 5 seconds.  If the client instance does not respect the given wait period, the AS MUST return an error. </del>  The response from the AS is a JSON object and MAY contain any of the fields described in response, as described in more detail in the

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: c7e84a97cc589eff531c783bfcaf307fa8ee92a6 Inspect the deploy log: Browse the preview:
As a bit random comment... I always wondered if it's allowed for the AS to provide a "delayed" response, or in other words, leverage the HTTP long polling mechanism just like for this response with the field. Of course, there will be definitely upsides and downsides to it. See URL for more info.
Since it's over HTTP, long polling is allowed regardless of whether we mention it or not. I personally don't see a reason to mention it explicitly here.
It's a continuation of the discussion started in URL which I would like to track as a separate issue. If we want to have that then the client should be able to wait and handle a delayed response say after 60 - 120 seconds, and the client should be able to gracefully handle various timeous (client and from the network infrastructure) and make a subsequent call, and the client should know what to do with the "wait" field when a timeout occurs in the previous step. I think it could be a great addition to this specification. Furthermore, take a look at and how they leverage the HTTP long polling mechanism.
The specification allows using the HTTP long polling mechanism against the OAuth2 token endpoint in somewhat similar circumstances. I had some spare time to research this topic a bit deeper and don't have a good answer on how it was possible for me to have the abovementioned specification out of sight. Again, it would be such a great thing to have a bit more instant notification mechanism in the specification core, I mean, not in its extensions or in one or another out of band/vendor-specific solution.
Continuing a Grant Request: Editor's note: What's a reasonable amount of time to wait by default so as not to DOS the server if the field is missing?
Might have to broaden the perspective and provide more general guidance on how to avoid/limit DDoS
I think we need general considerations as well, but this is a specific case where a naive implementation could accidentally DoS the system by polling too quickly.
yes. Then it's simple, anything around the minute should work.
Discussed in security considerations URL However, still no normative requirement in the polling section so this issue is staying open until that's in.
Need to add this to the interaction response section. I suggest "SHOULD NOT be less than five seconds" and "omission MUST NOT be treated as zero".

Revised text:
If a "wait" parameter was included in the response-continue, the client instance MUST NOT call the continuation URI prior to waiting the number of seconds indicated.  If no "wait" period is indicated,  <ins> the client instance MUST NOT poll immediately and SHOULD wait at least 5 seconds.  If the client instance does not respect the given wait period, the AS MUST return the error "too_fast" defined in response-error. </ins> The response from the AS is a JSON object and MAY contain any of the fields described in response, as described in more detail in the