Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!bywater!scifi!njs
From: njs@scifi.UUCP (Nicholas J. Simicich)
Newsgroups: comp.dcom.modems
Subject: Re: New "Alternate Connector For Use With ANSI/EIA-232-D"
Message-ID: <785@scifi.UUCP>
Date: 24 Sep 89 15:48:27 GMT
References: <870.251007A2@zswamp.fidonet.org> <328@gp.govt.nz> <8539@hoptoad.uucp> <287@van-bc.UUCP>
Reply-To: njs@scifi.UUCP (Nicholas J. Simicich)
Organization: Nick Simicich, Peekskill, NY
Lines: 39

In article <287@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes:
>In article <8539@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>>The standards bogons are at it again.
>
>Looks good, but can we have hardware flow control? Please.
>
>}Draft signal spec:
>}
>}	GND
>}	TX Data
>}	RX Data
>}	I'm Here (DTR)
>}	You're Here (DSR/CD)

Um, er, I think this is a problem.  DSR and CD are really two separate
things.  Let me try an example.  The modem is on, but is not
connected.  Is it there?  If it is connected, and on, I presume it is
there.  What if the connection drops.  Is it there?  But it really is
there, just the connection dropped.  How is this signaled?

Unfortunately, after dealing with this crap for a while, I can't
imagine that in band signaling of this condition would be a good idea.
You need another lead, and this lead has no valid counterpart from the
terminal side.

I'd rather not give up ring indicate, either, but that is less
important.

>}	TX Clock (synchronous modems and flow control)
>}	RX Clock (synchronous modems and flow control)
>}	+5V, fused and current-limited
>	You can Send
>	I can Send

This is a good addition, in my opinion.  Put it in the spec that
XON/XOFF is illegal!

-- 
Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)