Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nbires!hao!boulder!sunybcs!rutgers!mtune!jhc
From: jhc@mtune.ATT.COM (Jonathan Clark)
Newsgroups: comp.dcom.modems
Subject: Re: Partial RS-232 Solution - (nf)
Message-ID: <1177@mtune.ATT.COM>
Date: Fri, 11-Sep-87 01:30:09 EDT
Article-I.D.: mtune.1177
Posted: Fri Sep 11 01:30:09 1987
Date-Received: Sat, 12-Sep-87 16:03:25 EDT
References: <377@grand.UUCP> <51700004@tub.UUCP>
Reply-To: jhc@mtune.UUCP (Jonathan Clark)
Organization: AT&T ISL Middletown NJ USA
Lines: 61

In article <51700004@tub.UUCP> Carstenn Bormann (cabo@tub.UUCP) writes
at some length about the V.24 standard. I was impressed. I was unable
to disagree with any of the statements made, and that's pretty rare
for me.

I will comment that when the word 'correct' is used in the article the
term 'standard-conforming' should have been used: this is a nitpick.
The term 'correct' has too many religious overtones these days.

>RTS/CTS and DCD are an entirely different set of control lines,
>necessary only for half-duplex operation.

"Necessary", true. Although they are getting close to that for
full-duplex.

>Then somebody discovered that CTS is very useful for controlling the
>data flow from the DTE to the DCE, and wished that there was a similar
>pin for controlling the data flow from the DCE to the DTE.
>He missed (or didn't care for) the fact that CTS flow control never
>was end-to-end with the V.24 spec, and usurped the RTS pin for the
>entirely different purpose of a ``reverse CTS''.

I didn't originate this idea, but if I had I would have known that RTS
is used for something else *in the half-duplex case* (which I'm not
interested in), and called down curses upon the heads of the committee
who designed this originally that they didn't foresee the need and put
this usage of RTS into the standard. Then I would have knowingly
ignored the HimmelGottverdammt standard, 'coz it was stupid. It would
indeed have been nice to make RTS at one end map into CTS at the other
on a non-multi-point (even full-duplex only) line.

>Now, let's try to find out what we really want.

Yes, *that* is what is important. Standards which do not meet this
criterion are abandoned rather quickly.

>We don't need a ``carrier'' or any other ``modem control'' for
>connecting a terminal to a computer, we don't need RTS either. We do
>need, however, lines that indicate that the other side ``is there''
>(the equivalent of DSR/DTR in V.24 and DCD/DTR in the misguided UNIX
>world standard).  We also may need lines for flow control (the
>equivalent to Pin4/CTS in the hardware handshake world).

Yes. And let us not forget the case where some RS-232/V.24 network is
connecting the terminal to the computer. A network is buffered, and
this is where the problems crop up. Perhaps as the world moves towards
multiplexed interfaces and end-to-end protocols the requirement for
out-of-band flow control will be satisfied without having to resort to
this sort of chicanery, but that day is some way off.

I restate what I said some time ago in this discussion: RTS/CTS flow
control may not be in the standard, but it is too useful to do without.

>Technical University of Berlin (West, of course...)

As in 'the GDR doesn't have a University'...?
-- 
Jonathan Clark
[NAC,attmail]!mtune!jhc

An Englishman never enjoys himself except for some noble purpose.