Responding with no hats, but off the top of my head, DNS-over-CoAP defines a
similar-in-spirit but different-in-format "docpath" element. (See
https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap.)
I think there could be some value in a more generic "protocol endpoint
represented by a URI path, not just a host:port tuple" SvcParam, but no one has
defined one yet. However, note that it's possible for one SVCB record to
indicate multiple protocol options, and those multiple protocols might reside
at differing paths, as in this example indicating colocated DoC and DoH support:
_dns.example.org. 429 IN SVCB 1 dns.example.org (
alpn=h3,co dohpath=/{?dns} docpath )
So such a SvcParam would probably need the ability to represent a dictionary of
ALPNs and the paths associated with each. At that point, it could be simpler to
define a SvcParam per protocol as has already been done for DoH/DoC. However,
if you have a suite of related protocols where you can be confident the path
would be the same, you could certainly define a SvcParam which applied to all
of those at once.
________________________________
From: Michel Le Bihan <[email protected]>
Sent: Tuesday, August 19, 2025 3:11 PM
To: [email protected] <[email protected]>; [email protected]
<[email protected]>
Subject: Path Parameter Considerations for SVCB Records (rfc9460)
Dear IETF DNSOP Working Group,
Thank you for your response to my previous inquiry regarding ALPN
identifier requirements in RFC 9460.
I would like to raise a related question concerning path parameters in
SVCB records. In addition to the TLS/TCP and QUIC transports discussed
in my previous email, XMPP also supports WebSocket (RFC 7395) and BOSH
(XEP-0206) as transport mechanisms. These protocols require path
information that is currently discovered through well-known URIs (e.g.,
https://im.example.org/.well-known/host-meta
<https://im.example.org/.well-known/host-meta>).
I note that DNS over HTTPS addressed a similar requirement by
introducing the "dohpath" SvcParamKey (RFC 9461). However, creating
protocol-specific path parameters for each application protocol that
requires them seems to present scalability concerns.
My questions are:
1. Has consideration been given to a generic path parameter that could
be used across multiple protocols, rather than protocol-specific
keys like "dohpath"?
2. What is the recommended approach for protocols that require path
information when using SVCB records? Should each protocol:
* Define its own path SvcParamKey (following the DoH precedent)?
* Continue relying on well-known URIs for path discovery?
* Consider an alternative mechanism?
3. Are there architectural reasons for preferring protocol-specific
path parameters over a generic solution?
Your guidance on this matter would be valuable for ensuring consistent
implementation approaches across protocols that require path information
in their service bindings.
Best regards,
Michel Le Bihan
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
