5.1. Pre-connessione ottimistica e riutilizzo della connessione (Optimistic Pre-connection and Connection Reuse)

Se una risposta di indirizzo arriva prima della corrispondente risposta SVCB, il client può avviare una connessione come se la query SVCB restituisse NODATA (MAY), ma non deve trasmettere alcuna informazione che potrebbe essere alterata dalla risposta SVCB fino al suo arrivo (MUST NOT). Ad esempio, futuri SvcParamKeys potrebbero essere definiti per alterare il ClientHello TLS.

I client che implementano questa ottimizzazione dovrebbero attendere 50 millisecondi prima di avviare la pre-connessione ottimistica (SHOULD), come indicato nelle linee guida di [HappyEyeballsV2].

Un record SVCB è coerente con una connessione se il client tenterebbe una connessione equivalente quando utilizza tale record. Se un record SVCB è coerente con una connessione attiva o in corso C, il client può preferire tale record e utilizzare C come sua connessione (MAY). Ad esempio, supponiamo che il client riceva questo RRset SVCB per un protocollo che utilizza TLS su TCP:

_1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (
    ipv6hint=2001:db8::1 port=1234 )
                               SVCB 2 svc2.example.net. (
    ipv6hint=2001:db8::2 port=1234 )

Se il client ha una connessione TCP in corso verso [2001:db8::2]:1234, può procedere con TLS su quella connessione (MAY), anche se l'altro record nel RRset ha priorità più alta.

Se nessuno dei record SVCB è coerente con alcuna connessione attiva o in corso, i client procedono con l'istituzione della connessione come descritto nella Sezione 3.