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]
