Is your feature request related to a problem? Please describe.

Currently, clients can specify an integer historyLength field in MessageSendConfiguration and TaskQueryParams types to control how much history to return in a response, otherwise the full history is returned. Specifically:

• With historyLength=0, status messages produced by the server are dropped, so the client may miss context.
• With historyLength=N (a fixed integer N>0), responses often contain redundant history or still miss some newly generated messages.
• With unspecified historyLength (default), the full history of the task is returned, which takes more and more communication bandwidth with increasing number of communication rounds, resulting in higher communication latency.

In practice, the client may only need new messages after a known messageId. This requires addressing history relative to a known point, not an absolute count.

Describe the solution you'd like

In MessageSendConfiguration and TaskQueryParams objects, add the following fields:

{
  historyMode?: string; // takes value in {"full", "tail", "after"}, 
  historyLength?: integer; // a non-negative integer, required only when historyMode == "tail"`
  historyAfter?: string; // a messageId, required only when`historyMode == "after"`
}

Semantics of historyMode:

• full: return all available history for the task.
• tail: return the last historyLength (a non-negative integer) messages from the history.
• after: return messages strictly after historyAfter (a messageId).

Backward compatibility:
If the client does not specify historyMode, the server determines behavior by:

• If historyLength is given, the historyMode is tail.
• If historyAfter is given, the historyMode is after.
• Otherwise, the historyMode is default to full.

This behavior is backward compatible with the current behavior, which only uses an optional historyLength field.

Examples Usage:

1. In a multi-turn conversation, a client knows the last message it saw (messageId: abc123…) and wants only newer messages:

Request (message/send)

{
  …
  "historyMode": "after",
  "historyAfter": "abc123-…"
}

Response:

{
  …
  "history": [
    { "messageId": "def456-…", "role": "agent", "parts": [ … ] },
    { "messageId": "ghi789-…", "role": "agent", "parts": [ … ] }
  ],
  ...
}

2. A client wants to retrieve the history of a previously initiated task.

Request (tasks/get)

{
  "historyMode": "full"
}

Describe alternatives you've considered

Alternatives:

• A timestamp-based historyAfter: This might introduce clock skew and ordering ambiguities. Using messageId is simpler and unambiguous.
• A history cursor at the server side: This increases server implementation complexity.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct