More naming around Reply-From

[chrysn]

Sorry to start this just after Reply-To became Reply-From. Working on transport-indication sent me here, and now I wonder:

Is Reply-From a specific usage pattern of the more general "and by the way this is my address" option? The places where I've also seen the need for the same option are:

• When a server suspects traffic misdirection and wants to send its own canonical address (currently the only related text is in Appendix D of transport-indication where it is in an EAD rather than a CoAP option, but that is being overhauled)
• Similarly, when a server wants to switch transports in Onion OSCORE in the scenario where there is a difference between introduction and rendezvous node.
• When a client sends a request, expects role reversal, but wants a specific host name to be used rather than just the automatic role reversal address.

I'm not sure yet those have all the same semantics as Reply-From, but if they have, maybe they should be one option. (If all their semantics differ from Reply-From, then there is nothing to be done here, other than be aware that Reply-From will be the first in a series of options with similar structure).

(Relatedly, core-wg/corrclar#10 (comment).)

[marco-tiloca-sics]

Is Reply-From a specific usage pattern of the more general "and by the way this is my address" option?

I think it's a bit different: the Reply-From option is added by the proxy (not by the origin server), and provides the client with "instructions" about where to send a follow-up request that reaches the originator of the response.

In most cases, that's actual addressing information of the origin server. In a particular case involving a reverse-proxy, that's addressing information of that proxy (such that a request sent there will be forwarded to the originator of the response).

• Similarly, when a server wants to switch transports in Onion OSCORE in the scenario where there is a difference between introduction and rendezvous node.

I should double-check, but I thought that the server (the hidden service) would inform the origin client about this particular switch in the payload of a protected response, i.e., the only one sent back to the client in the first circuit used to establish a contact.

I'm not sure yet those have all the same semantics as Reply-From, but if they have, maybe they should be one option. (If all their semantics differ from Reply-From, then there is nothing to be done here, other than be aware that Reply-From will be the first in a series of options with similar structure).

At a first look/thought, they seem to be different but relatable, so part of a series/cluster :-)