1. When the DTE (Data Terminal Equipment: eg a terminal) is powered on and ready to receive data, it asserts DTR (Data Terminal Ready).
2. When the DCE (Data Communications Equipment: eg, a modem, or other device communicating with the terminal) is ready, it asserts DSR (Data Set Ready).
3. In an actual modem configuration, when the modem has established a connection with a remote modem, it asserts CD (Carrier Detect).  Similarly, when an idle modem receives a phone call attempt, it asserts RI (Ring Indicate).  Depending upon the modem configuration and what is connected to it, the terminal may assert DTR, signalling the modem to answer the ringing phone line (and subsequently asserts CD).  While this is interesting, it is normally not a factor in the case at hand;  I've only included it for context.
4. Normally a terminal that is ready to send asserts RTS (Request To Send).  This usually stays high for the duration of the connection (an exception would be half-duplex modems, which is not pertinent here).
5. Typically, modems could receive data from a terminal at a much higher rate than the modem could send to the remote modem, and as a result, had an internal buffer.  The default state of a ready modem was to assert CTS (clear to send).  However, if the buffer got too close to being full, a modem would drop CTS until it had transmitted (emptied) most of the transmit buffer.

1. DTR and DSR are asserted when the respective devices are functionally ready, and stay in that state until the communications session is over.  Eg:  A printer (DCE) asserts DSR when its power-on sequence in complete, until power-off.  A software communications program (DTE) typically asserts DTR when the program opens the serial connection, until it closes the connection.
2. RTS and CTS are used for flow control, just as above.

When SOFTWARE flow control is used:

1. RTS is asserted by the DTE at the same time as it asserts DTR, and CTS is asserted by the DCE at the same time as it asserts DSR.
2. One or both of the devices sends X-off and X-on bytes to tell the other device to suspend and resume transmission, respectively.

Sometimes two DTE devices need to communicate, and a wiring change is made in the normally straight-through cable, so that what one DTE device thinks is DTR/RTS/TX, the other device sees as DSR/CTS/RX.  Such is the "null modem" cable.  Some manufacturers of devices don't understand this or related wiring issues, leading to the need for "gender changers", but this is not pertinent here.

One important feature of all of the above, is that each such device acquires its own power.

However, with most Amateur Radios, the radio cable usually does not bring anything except "ground" and the "TX" and "RX" data lines.  This is the case for all Icom radios that I am aware of, as well as and most handhelds from other manufacturers.  My Yaesu FT-897D is an exception;  the serial cable provides power to its internal serial converter.

For some Icom radios (eg, the ID-880H and IC-2820H) that use the Icom OPC-1529R cable, it's a simple three-wire cable providing ground, TX, and RX.  Presumably these are at RS-232C acceptable levels (that's a whole different discussion).  Other cables (eg, the Yaesu one for the Yaesu FT-897D) have a little circuit board in the RS-232C/DB-9 shell that does level conversion (and needs power, except for the few radios where the cable provides the power).  Still other cables, like the ones that split out TX and RX signals from a single wire, have additional circuitry for that purpose.

Both of the latter cases must get their power from the DTR and/or RTS lines from the connected computer.  These signal lines were never intended to provide power, but since modern circuits draw so little power, using DTR and/or RTS for power doesn't create an issue if done correctly.

As I noted in the feature request, some cables want both DTR and RTS on, and use ground for the voltage reference base.  Others want RTS low and DTR high, and some want the reverse.