I'll note that CoAP is currently going through a similar process, registering ALPNs to distinguish TLS, DTLS, and even plain-text in SVCB records.
________________________________ From: Ben Schwartz <[email protected]> Sent: Monday, August 18, 2025 4:25 PM To: Michel Le Bihan <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [DNSOP] Clarification on ALPN Transport Binding Requirements in rfc9460 SVCB Record ________________________________ From: Michel Le Bihan <[email protected]> Sent: Monday, August 18, 2025 11:41 AM ... 1. What was the rationale for requiring ALPN identifiers in SVCB records to uniquely identify the complete protocol suite, including transport? When choosing among the various endpoints, clients need to know which of those endpoints support a compatible ALPN ID. For example, an HTTP/1.1-only client should not attempt to connect to an HTTP/2-only server, even though both use the same transport protocols. This means that ALPN IDs must be present in the SVCB record. Given that ALPN IDs must be present, including the transport explicitly would normally be redundant. It would also create the possibility of illogical or self-contradictory records, such as a record claiming to support HTTP/3 but not QUIC. At the time this design was selected (2020) [1], the only ALPN IDs that didn't uniquely identify the transport were STUN/TURN (RFC 7443), which seemed unlikely to use SVCB anyway. 2. Were alternative designs considered, such as: * Having a separate SvcParam to indicate supported transports Yes, that was the previous design. * Allowing multiple transport protocols to be associated with a single ALPN identifier within the SVCB framework No, as this would create ambiguity about whether an endpoint is compatible with the client. * Using a structured ALPN value that could encode both application protocol and transport This can be done by registering unique ALPN values for each transport. For example, DNS uses the ALPN IDs "dot" for TLS and "doq" for QUIC. 3. For protocols like XMPP that have chosen to reuse ALPN identifiers across transports, what is the recommended approach for using SVCB records? I recommend allocating 4 new ALPN IDs, for XMPP (client/server) x (TLS/QUIC). Clients and servers SHOULD offer both the old and new ALPN IDs (at least during a transition period of several years), but only the new ones can appear in SVCB records. Many other arrangements are possible using custom SvcParams, but that will take a lot more work to specify, understand, and implement, for no obvious benefit. --Ben [1] https://github.com/MikeBishop/dns-alt-svc/pull/116#issuecomment-595320955
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
