diff --git a/docs/root/api-docs/xds_protocol.rst b/docs/root/api-docs/xds_protocol.rst index 77428cc932ad8..b95b6ec39ac50 100644 --- a/docs/root/api-docs/xds_protocol.rst +++ b/docs/root/api-docs/xds_protocol.rst @@ -851,13 +851,32 @@ names, which the server thought the client was already not subscribed to. The server must cleanly process such a request; it can simply ignore these phantom unsubscriptions. +In most cases (see below for exception), a server does not need to send any response if a request +does nothing except unsubscribe from a resource; in particular, servers are not generally required +to send a response with the unsubscribed resource name in the +:ref:`removed_resources ` +field. + +However, there is one exception to the above: When a client has a wildcard subscription ("*") *and* +a subscription to another specific resource name, it is possible that the specific resource name is +also included in the wildcard subscription, so if the client unsubscribes from that specific +resource name, it does not know whether or not to continue to cache the resource. To address this, +the server must send a response that includes the specific resource in either the +:ref:`removed_resources +` +field (if it is not included in the wildcard) or in the +:ref:`resources ` +field (if it *is* included in the wildcard). + Knowing When a Requested Resource Does Not Exist ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -When a resource subscribed to by a client does not exist, the server will send a :ref:`Resource -` whose :ref:`name ` field matches the -name that the client subscribed to and whose :ref:`resource ` -field is unset. This allows the client to quickly determine when a resource does not exist without +When a resource subscribed to by a client does not exist, the server +will send a +:ref:`DeltaDiscoveryResponse ` +message that contains that resource's name in the +:ref:`removed_resources ` +field. This allows the client to quickly determine when a resource does not exist without waiting for a timeout, as would be done in the SotW protocol variants. However, clients are still encouraged to use a timeout to protect against the case where the management server fails to send a response in a timely manner.