[DNSOP] Re: Path Parameter Considerations for SVCB Records (rfc9460)

[Mike Bishop <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, August 19, 2025 3:11 PM
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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