Their replies are only obtuse because you fail to see that you’re being made fun of for having such a ridiculous pedantic position about this. “Terminal” does not mean shell when you read the Telnet RFC. It means TTY. A human to machine interface. MUDs implement the Telnet protocol and provide a remote TTY. What’s running on the terminal is absolutely irrelevant.

▲

RupertSalt 6 hours ago | parent [-]

It is not pedantic and many respondents are simply obstinately conflating the tcp port with the protocol and with the server software. You have done the same thing. Did you not read my statement where I said it is perfectly fine and even preferable for MUDs to implement TELNET? Where did I ever oppose the implementation of TELNET protocol?

Yes, when the TELNET protocol is in use, the applications are irrelevant to the underlying substrate of an NVT. But when port 23 is in use, everything changes. That is my point. And there seems to be a brigade of mudders who are butthurt about losing their pet TCP port in this. They cannot mock me because they are wrong. Their wizards chose poorly decades ago.

▲

zenethian 6 hours ago | parent [-]

Can you show the exact line in the RFC or IANA port reservations that says it has to implement a shell login interface with the Telnet protocol if it’s on port 23? Because I can’t find it. Nothing says that anywhere.

▲

RupertSalt 6 hours ago | parent [-]

I literally already did. And it is not merely the RFC which specifies it. The RFC defines the protocol and really leaves it open-ended for any sort of implementation.

What defines port 23/tcp is the longstanding usage and the original understanding of a "remote terminal" or NVT. In 1983 when the IETF described the NVT, it was simply understood that a terminal, or "canonical console", was a method to access a timesharing system and log in as a user. If you went to a "terminal lab" or you sat down at a desk with a "terminal" or "teletype" or any of its predecessors, you were preparing to log in and do some programming or data processing.

There were literally no terminal labs where you would sit down and begin playing Centipede, Asteroids, or PONG. Those were completely different concepts of "consoles" and "cabinets" and the IETF did not stutter when they defined an NVT.

Every Unix implementation, every router and network device, practically anything with an Internet connection implemented a "shell" login on port 23 or it did not. There were plenty of systems with /usr/games and a plethora of leisure-time activities, but surprisingly they did not default to using port 23/tcp. It has been long-standing tradition, and convention, that the TELNETD service operating on 23/tcp is what a user expects to find when they connect.

MUD admins and wizards who put their servers on 23/tcp necessarily needed another way to log in and manage their server. I am surprised that they were so easily able to usurp telnetd if this was the status quo. Was sshd already established for them or something? Did they just resort to rlogin instead? I'm genuinely clueless and curious how it was so easy to usurp 23/tcp and use it for MUDs.

Because my community often ran them clandestinely, and we always ran them unprivileged, so there would literally be no way for the server to start on port <1024 -- it never ever had root access! If your MUD ran on port 23, that's dangerous because at some point, somewhere, some time, it enjoyed root access, and hopefully dropped that UID 0 immediately after the bind()!

▲

ylow 4 hours ago | parent [-]

Just for you I will switch my FTP server to run on Port 23.

	▲	RupertSalt 4 hours ago \| parent [-]
		Data or Control channel? TCP or UDP or SCTP? The world's your oyster, man