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)