It's strange that cisco's note
IIRC, the author was actually at Telebit when he designed the protocol. Cisco acquired Telebit in 1996, and then wasted most of them :-(
because if you use binary data and not only text how you will decode if is a data control packet or raw data?.
Oh, that's well established. RFC2217 is a telnet option, and telnet defines how to send binary data while still having in-stream commands (essentially, the command lead-in character gets doubled if you want to send it as data.) RFC2217 doesn't actually add a lot that wasn't already implemented; the main thing being the reading and setting of the extra serial signals. (There are other telnet options for flow control and bitrate.) Having separate tcp connections for commands and data might make sense, depending the the relative cost of a second connection vs having to scan every byte in the data stream. Which is very ambiguous, since one of those tends to be an OS-internal cost, and one is a user-program cost.
The main purpose of the RFC2217 "comport" protocol is to permit a PC-like system to manipulate a remotely (internet) connected com port as if it were local. So you could do an AVR or PIC serial-port bit-banging device programmer through an expensive terminal server port instead of your cheap local port, or something. As if the indeterminate timing of ... everything ... wouldn't actually matter. Hmmph.
Aside from serial ports disappearing, digtial modems being all the rage, and people suddenly switching to things like ssh for better security, I think there was a feeling that people who needed this sort of functionality would pay for it.
There were several open source "Comm Server" projects, designed to turn an old pc into a dialup server based on linux or similar, sort of the way there were similar projects to implement router. I'd be surprised if there weren't ANY open-source implementations that implement this.
How about: http://sourceforge.net/projects/telnetcpcd/