MRTR url-mode: standardize the "still waiting" response (state-only InputRequiredResult) + retry/cancel guidance #2920

Summary

For url-mode elicitation under MRTR, the spec notes that a round-2 retry "may need to block until the request is fulfilled," but it does not define a bounded, non-blocking idiom for "not done yet," nor a timeout/cancel verb.

Problem

A server that brokers an out-of-band flow (OAuth consent, credential entry, payment, external approval) often should not hold the round-2 request open until the user finishes — that ties up a connection for an unbounded time and doesn't compose with stateless/HTTP deployments. The server needs a sanctioned way to answer a premature retry with "still waiting, try again."

Server Requirement #6 already permits returning an InputRequiredResult with the same requestState and no new inputRequests, which is the natural "still waiting" signal. But it is not named or recommended as the idiom, so:

• implementers don't know it's the blessed pattern (vs. blocking, vs. an error),
• there's no guidance on client retry/backoff bounds, so clients either hammer or give up,
• there's no standard cancel verb for the user abandoning the out-of-band flow.

Request

1. Explicitly bless the state-only InputRequiredResult (same requestState, empty/absent inputRequests) as the canonical "still waiting" response for an in-progress out-of-band interaction.
2. Add client guidance on retry cadence / backoff bounds for that response (and clarify whether notifications/elicitation/complete is the preferred wake signal vs. polling).
3. Specify a cancel/abandon path (verb or inputResponses action) for when the user dismisses the out-of-band flow, so the server can release requestState deterministically rather than relying on TTL.

Context

Implemented the host side of MRTR url-mode and hit exactly this ambiguity: the state-only-refresh response works, but whether it's the intended idiom, how aggressively to retry, and how to signal cancellation are all left to implementer guesswork.