💾 Archived View for bbs.geminispace.org › u › ERnsTL › 1665 captured on 2023-07-22 at 18:02:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
I would also find an SRV record useful. It would add not more than a paragraph to the spec. You could mark use/lookup of the SRV record as optional for client implementations.
2023-06-08 · 6 weeks ago
I support this as well. I don’t think it adds significant complexity, and it could definitely be marked as optional.
I'm curious how you think making this optional would improve things rather than add confusion. If it were a mandatory part of a spec, then any client would be able to look up a server regardless of the port it's running on. If it's optional and I need to run a server on a non-default port for one reason or another, then a client that supports SRV will load the site just fine, but a client that doesn't will probably leave a user confused when his buddy says it works just fine.
2023-06-13 · 6 weeks ago
I also think SRV records could be used for multi-hosting in a sane way. If I have an account on a server with many other users and I don't have root access, then I'm essentially forced to use a non-default port for any server process I want to run. If I run a server for a protocol that requires SRV records to be defined, then many users could run their own processes on arbitrary ports, each with their own domain CNAMEs and SRVs with no problem.
@winduptoy good point. I guess what I mean is no SRV record is necessary if one wants to use the default port. It shouldn’t really be an optional feature for clients though, that would be confusing.
SRV records — Any thoughts on making SRV records part of the spec? I think it adds a lot of flexibility for the server operator without much cost and can be pretty beneficial when your ISP does something boneheaded like block port 1958.
💬 winduptoy · 7 comments · 1 like · 2023-06-03 · 7 weeks ago