1. I have tested it with TREP 3.0.1.E1 and found that TREP doesn’t cache the REDIRECTED status. It forwards the status to the consumer. If the consumer requests the same item again, the request will be forwarded to the provider. Therefore, the provider needs to send the REDIRECTED status again
   
2. The REDIRECTED message indicates the stream is closed and it must contain the new identifying information in the message key. Otherwise, the consumer will get this status text: “F18: Received redirect without new item name.”
   
3. REDIRECTED is a stream state so it can be used with any stream
   
4. Yes, NIP can publish REDIRECTED status and the subscribing consumers will get the REDIRECTED status with the new identifier. However, if the consumer requests the same item again after the REDIRECTED status is published, it will get “F10: Not In Cache” because the stream of that item between NIP and ADH has been closed

RSSL/Redirect is supposed to be equivalent to an SSL/Rename message.

TREP is designed to support RSSL/Redirect and is explicitly supported by ADS multicast as added in UPA 7.6. This covers warm-standby situations when a consumer requested symbol X and is redirected to symbol Y and then has failed over to another ADS and the item stream for symbol X must continue being valid.

RSSL/Redirects operate on any item streams and can be used to bounce subscriptions to or from private streams.

Both interactive and non-interactive providers can send RSSL/Redirect messages, although for the case of private streams this would not be very useful for broadcast-only.

All the RFA and UPA examples and ValueAdd libraries only cover bouncing between public and private streams. This highlights that almost zero clients will understand RSSL/Redirect messages when received directly.

The outstanding question is whether or rather how to implement the RSSL/Redirect so that TREP can do this on a clients behalf, basic testing with a modified RsslProvider can close the stream id but does not open a new one.