What I meant in my remark about Telnet is that, if you just want is a bidirectional byte pipe to e.g. run a terminal over, then you just need TCP or anything else providing the same abstraction, like TLS-over-TCP or TCP-over-IPsec; whether you then choose to run a getty on that terminal is not for the network to care. (I don’t believe you can get netcat to drive a PTY, so you’ll need e.g. socat. And of course if you want cryptographic authentication then you don’t need or want a getty.)

Telnet, on the other hand, is quite a bit fancier than that and has a fairly involved feature negotiation mechanism for terminal connections that is not entirely in line with the prevalent DEC/Unix tradition. As admittedly one of the funkiest examples of what you can do with it, there is for instance a mode[1] where the client is asked to emulate a terminal of the IBM 3270 lineage. (To a practicioner of the aforementioned DEC/Unix tradition, those feel like the marsupials of terminals: everything is functionally there, but primitive and derived are occasionally flipped and some features are oddly weak or misdesigned due to a lack of competition.) So if you do actually use Telnet the protocol, by all means, I’ll be delighted to learn what you do with it (partly why I asked in the first place). But if you just need a pipe, then TCP is enough, and netcat or socat make fine ad-hoc clients.

[1] https://tools.ietf.org/html/rfc6270