Here is a link to the RFC2217 specification:
This is a quite old spec (nearly 20 years now). The high level appears that one can use a telnet client to connect to a telnet server that then drivers a UART/Serial port. For example, to drive an "old fashioned" dialup-modem connection.
My gut feel is that there would be little value in this for flashing from an ESP32 perspective. We would basically need a telnet server that is RFC2217 aware that would be UART connected to the ESP32. Then we would need a telnet client to connect to that telnet server over which the image and related protocols would be streamed to the RFC2217 compliant telnet server. This would mean that we would need to construct an ESP32 "flasher" (eg. esptool) to become a telnet client. And its here where I start to raise questions.
For me, telnet was always a human <-> computer piece of function. Telnet clients "owned" user interaction plus TCP/IP networking to a peer server app (the telnet server) which interacted with the OS to receive user input and return system output. If we were to use RFC2217 to drive the ESP32 UART interface, it seems we wouldn't be leveraging and user interface function of a telnet client ... and hence our "telnet client" compatible esptool would be an odd beast. While, in principle, we could leverage the pieces defined here, I would question if we didn't have a better story.
For example, today we have the ability to run up a socket server in a few lines of code, receive a stream of data (the file to be flashed) and upon receipt, invoke a system command (esptool for example).
With that in mind, let us not look at the technology available, but rather clearly state the problem we are trying to solve. From the story so far, I am guessing:
1. I have a PC to which an ESP32 is attached.
2. I have a second PC which is networked to the first PC.
3. From the second PC, I want to be able to flash the ESP32 attached to the first PC.
I think we can "chain" a solution together to do this with sftp, ssh, node.js or a variety of other tools without wandering into "old fashioned" (opinion) telnet based stories.