Do we need more guidance for clients on use of tokens?

[mirjak]

We recently added the following text:

As specified in {{Section 9.3 of QUIC-TRANSPORT}}, the server is expected send a new
address validation token to a client following the successful validation of a
new client address. In situations where multiple paths are activated, the
client may be recipient of several tokens, each tied to a different address.
When considering using a token for subsequent connections, the client ought to
carefully select the token to use, due to the inherent ambiguity associated
with determining the exact address to which a token is bound. To alleviate such a
token ambiguity issue, a server may issue a token that is capable of validating
any of the previously validated addresses.

However, maybe we need more guidance for client on usage. E.g. always use the last one...? Or maybe we need any normative text here?

[kazuho]

That's a good point. Yes, it might be a good idea to give more advice here.

Regarding if we need normative text, RFC 9000 section 8.1.3 has the following statement:

Clients might receive multiple tokens on a single connection. Aside from preventing linkability, any token can be used in any connection attempt. Servers can send additional tokens to either enable address validation for multiple connection attempts or replace older tokens that might become invalid. For a client, this ambiguity means that sending the most recent unused token is most likely to be effective. Though saving and using older tokens have no negative consequences, clients can regard older tokens as being less likely to be useful to the server for address validation.

It is handwavy indeed, but maybe just having a link to this section is sufficient, as nothing has changed from QUIC v1 in terms of having multiple paths on any of which a connection can be resumed.

[mirjak]

I added a ref in PR #289. I think we can close this issue after merge.