Why telnet is considered to be a protocol? Isn't it just a simple TCP send/echo program?
Telnet is defined in RFC 854. What makes it (and anything else) a protocol is a set of rules/constraints. One such rule is that Telnet is done over TCP, and assigned port 23 - this stuff might seem trivial, but it needs to be specified somewhere.
You can't just send whatever you want, there are limitations and special meaning to some things. For example, it defines a "Network Virtual Terminal" - this is because when telnet was established, there could be many different terminals: A printer, a black/white monitor, a color monitor that supported ANSI codes, etc.
Also, there's stuff like this:
In summary, WILL XXX is sent, by either party, to indicate that party's desire (offer) to begin performing option XXX, DO XXX and DON'T XXX being its positive and negative acknowledgments; similarly, DO XXX is sent to indicate a desire (request) that the other party (i.e., the recipient of the DO) begin performing option XXX, WILL XXX and WON'T XXX being the positive and negative acknowledgments. Since the NVT is what is left when no options are enabled, the DON'T and WON'T responses are guaranteed to leave the connection in a state which both ends can handle. Thus, all hosts may implement their TELNET processes to be totally unaware of options that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood.
In modern times, most of the stuff isn't really that important anymore (then again, telnet as a protocol isn't being used much anymore, not just because it lacks security) so in practice it boils down to send/echo unless you have to actually interface with terminals.
The fact that telnet “just works” when connecting two terminals is in itself a protocol decision: the designers of telnet decided to use a model with “network virtual terminals” at either end of a TCP connection, and decided to model those virtual terminals on basic terminal features (teletypes really).
Beyond that, telnet is more than a simple TCP-based echo service; it supports control codes, sent in-band, for various purposes. It is codified in RFC 854.
A sub-system called "Telnet" is proposed which is a shell program around the network system primitives, allowing a teletype or similar terminal at a remote host to function as a teletype at the serving host.
This is from RFC 15, which is mentioned in wikipedia "telnet". This article also starts by calling telnet a "application protocol".
The RFC 15 is from September 1969 - just some days ago I heard an interesting interview with the guy who made the first "internet" connection, exactly 50 years ago. His story went like that:
"Unlike N. Armstrong, we hadn't thought of any special message. But after typing "lo" (for "login"), the system crashed. So "lo" (as in "lo and behold") was the first two characters transmitted over the internet. In retrospect, we couldn't have thought of something better."
(Here is some of that interview: wiki arpanet Kleinrock)
Telnet predates TCP/IP. RFC 15 speaks of "network primitives". Because of TCP/IP, telnet was only left to take care of the "rest", the application layer (the "negotiated options" in RFC854).
Yes, telnet is quite simple, even without TCP. RFC 15 ends with:
TELNET subsystem constitutes a "level 0" network program which will quickly be surpassed. It is, however, simple enough to be working fairly soon.
"Protocol" is used with telnet because inherently two (different) systems need to talk in one "language".
RFC 854 also explains the concept:
The TELNET Protocol is built upon three main ideas: first, the concept of a "Network Virtual Terminal"...