I want to propose an addendum to the EIA-232 standard that recommends
implementation of RTS/CTS full duplex mode flow control. Obviously the
EIA-232 standard can't be changed to require this since it's an extension
to an already approved standard. But it can become a recommended
extension which, I believe, would tend to cause vendors to be more
pliable to requests for this feature. It would also improve vendor
confidence that they weren't wasting time on a mechanism that might be
explicitly declared as wrong by IEEE.
Who do I contact to petition for this extension? If someone will post
an address to mail to, I think everyone should mail a letter expressing
their view on this (either for or against.)
Tired of overrun buffers,
Why mess with "The Standards Process"? Sales critters who do not sell what
you want to buy will still find a standard that justifies their inaction.
The beauty of standards is that there are so many that you can always find
one that suits your business needs.
Standards can be ok for codifying existing, de facto standards, such as the
RTS/CTS hack. They are great for archiving complicated de facto standards,
but not needed for things as trivial as RTS/CTS flow control. Since there
is no arguement about what it is, what difference would it make if EIA also
said what it is?
The Standards Process can be a monster when it decides to start designing.
If The Standards Process got its mitts on RTS/CTS flow control, we could
end up with yet another "equally disadvantageous compromise" like the famous
ones in the past. Do you want a Standard that says RTS must be + unless
the DTE can receive more than 10KB or that the DCE must react to RTS going -
no sooner than 150 milliseconds (or whatever the old RTS-CTS delay was)?
Such idiocies cannot be ruled out, and would be far worse than the current
situation, since many vendors would be constrained to implement the
standard and only the standard.
It would take years to get a de jure standard approved. We can hope that
by then async modems will be dead and buried by ISDN (another success story
of The Standards Process).
How many connnectors do the 1970's "replacements" for RS-232 say you have
to have? How many vendors support both connectors? How many users want to
buy full RS-422? If Standards had the force of law, would you be able to
buy RS-232, let alone RS-232-with-RTS/CTS-flowcontrol?
>It would take years to get a de jure standard approved. We can hope that
>by then async modems will be dead and buried by ISDN (another success story
>of The Standards Process).
All of AT&T's ISDN voice/data phones and data only terminal adapters
that have RS-232 interfaces support full duplex RTS/CTS flow control
(from day one). Whether or not async modems disappear to be replaced
by ISDN, full duplex RTS/CTS flow control will be around for awhile.
The real question is what, if anything, will be able to overthrow
the RS-232 interface. Several alternatives have been tried. None
have succeeded in achieving enough market presence to relieve us
of RS-232 headaches.
RS-232 fulfills three rolls. One is that it is a (ahem) "standard
interface", a common denominator that lets me plug in equipment
from a wide variety of vendors without needing a new device
driver. The second is that it lets me connect equipment at
distances much farther than the length of my CPU bus. And the
third (and possibly most important) is that it is cheap to
I submit that the "standard interface" roll will always be needed.
I submit that with workstations and workgroups becoming the norm,
the distance issue is not so important anymore. It has to be
longer than the CPU bus, but 10-20 feet max would suffice. Dirt
cheap will always sell.
I'd like to see a major vendor cook up a dirt cheap interface,
full duplex and capable of at least 10 times the speed of RS-232,
with full duplex out of band flow control and make it a standard
feature on all of their peripherals (along with an RS-232 port),
much as most printers these days have both serial (for compatibility)
and parallel (for speed) ports standard.
High speed (>19.2) modem manufacturers and ISDN T/A vendors have already
found that their devices can't sell into a market whose common
interface is generally limited to 19.2 (due to HW and SW limits).
Yet, none of them have taken the obvious step.
Rick Richardson - PC Research, Inc., uunet!pcrat!rick, (201) 389-8963
I don't know if this is possible, but for folks thinking of going to a
386, and trying to decide what UNIX/XENIX product to get for the
machine, it would be nice to know UP FRONT who does and who does NOT
support the RTS/CTS flow control. Often its pointless to ask the
vendor, one will get responses from 'yeh, right', to 'I dunno', and
one will not find out for sure till they have committed and put down
the $$$$ for the product. Then, it is a bit late. It would be very
nice to have this information UP FRONT, so those that don't provide
RTS/CTS can be eliminated. For folks with 2400 bps modems, its
probably no big deal, but if a Telebit is going to be used, it becomes
I know I would find the information very useful, as I am thinking of
going to a 386 (funds permitting).
pat@rwing (Pat Myrto), Seattle, WA
WISDOM: "Travelling unarmed is like boating without a life jacket"
Date: Mon Feb 19 11:31:26 EST 1990
From: attmail!tni...@uunet.UU.NET (Toby L. Nixon)
Subject: Hardware flow control in EIA-232
Mr. Leedom, I am the representative from Hayes Microcomputer
Products to the standards committees in the USA and
internationally that develop standards for modems. I am chairman
of the EIA/TIA technical committee that developers protocols for
use between DTEs and DCEs (computers and modems), which is
technical subcommittee TR-30.4 of the Telecommunications Industry
Association (TIA). I'm also a member of the TIA TR-30.2
committee which develops USA standards on DTE-DCE interfaces;
EIA-232 was developed in, and is the responsibility of, TIA
I'm happy to report to you that TIA TR-30.2 has already addressed
your concern. Initially the hardware flow control issue was
mentioned in a Technical Systems Bulletin issued by TIA.
However, TR-30.2 last week finalized work on ANSI/EIA/TIA-232-E
("E" being the version level), which should go out for industry
ballot within the next month. TIA-232-E will include the
definitions of the use of the CTS circuit (CCITT V.24 circuit
106) for flow control of the DTE by the DCE, and of the "RTS"
circuit for flow control of the DCE by the DTE. In reality, it
is not "RTS" that is used for this, but "RTR" (Ready to Receive),
which is CCITT V.24 circuit 133; TIA-232-E and related
international standards have been updated to show that circuit
133, when implemented, shares the same pin as RTS (Request to
Send), and that when 133 is in use, RTS is assumed to be ON.
TIA-232-E does not MANDATE that hardware flow control be used --
certainly there are many devices that do not need it that have
232 interfaces -- but it does give a clear explanation of what
pins are used. Manufacturers can still argue that it is not
"required" by the standard, but they can't argue that its "not a
part of the standard". It IS standard. In fact, the
international standard for error control in modems, V.42,
specifically indicates that circuits 106 and 133 should be used
for hardware flow control. As a user and purchaser of data
communications equipment, one can indicate that this function is
required, or you'll simply buy somebody else's equipment; that
should get these stuck-in-the-mud vendors hopping.
If you would like to be on the mailing list to receive a copy of
TIA-232-E and have the opportunity to respond to the industry
ballot, contact the Telecommunications Industry Association in
Washington, DC, 202-457-4900; Ceclia Fleming is the supervisor of
Publications. For your reference, the chairman of TIA TR-30.2 is
Fred Lucas of General Datacomm, Middlebury CT 06762-1299,
203-574-1118. Of course, feel free to contact me if you have any
One last thing: you make the comment in your message: "Obviously
the EIA-232 standard can't be changed to require this since it's
an extension to an already approved standard." This couldn't be
further from the truth. As an active participant in the
standards-making process, I can assure you that standards are
under continuous review, constantly being revised and improved.
ANSI rules require that ALL standards be reviewed at least every
five years, and either reaffirmed, revised, or rescinded. The
committees are eager to hear from users about concerns regarding
standards and are happy to hear suggestions and recommendations
on improvement of standards. One of the biggest problems in the
standards community is that the active participants tend to be
equipment manufacturers, which don't always have a broad view of
the needs and desires of the user community; we just love it when
a user wants to become involved in the process! I assure you
that your participation, at whatever degree, would be most
welcome in TIA TR-30 and its subcommittees, as would that of any
other interested user.
Toby L. Nixon
Principal Engineer, Hayes Microcomputer Products Inc.
Chairman, TIA TR-30.4
P.S. I'm sorry I don't have direct access to usenet mail, or I
would have responded there (your message was forwarded to me by
Stuart Lynne of UNifax [thanks, Stuart]). Please feel free to
post my message for public consumption if you desire.
Fax: +1-404-441-1213 Telex: 6502670805
Phone: +1-404-449-8791 Compuserve: 70271,404
MCI MAIL: TNIXON (267-0805) AT&T Mail: !tnixon
Telemail: T.NIXON/HAYES Genie: TOBY.NIXON
BBS: 1-800-US-HAYES FidoNet: 1:133/301
X.400: C=US / AD=ATTMAIL / PN=TOBY_L_NIXON / DD=TNIXON
Mail: P.O. Box 105203, Atlanta GA 30348, USA
Express: 6610 Bay Circle, Norcross GA 30071, USA
SCO Xenix does - 386/ix doesn't (as distributed). There are replacement
drivers for 386/ix which increase serial IO throughput and add CTS/RTS
Larry Snyder, Northern Star Communications, Notre Dame, IN USA
uucp: larry@nstar -or- ...!iuvax!ndmath!nstar!larry
4 inbound dialup high speed line public access system