peter@ficc.uu.net (Peter da Silva) (12/21/89)
In article <8912200236.AA25652@ucbvax.Berkeley.EDU> cire@CISCO.COM (cire|eric) writes: > Yes Computer based telecommunications has a great deal of more utility > than FAX but I don't think that is the point. You must first make the > connection before all that starts making a difference. OK. Let's do it. What should the communications look like? UUCP? Dial-up SLIP? Or something more like FIDO? All we need to do is agree on a standard and then we can start saying: mail 7134385018!peter Or: mail peter@7134385018.PHONE And folks with home PCs can do the same. Just make it simple enough that any bozo with a copy of PCTalk can hack it up. Chat scripts for UUCP, and baud rates, are the biggest problem. How about this: To start up the session, you need to send the string "email<CR>". This should handle the login problems. You keep sending this string with a 1 second delay until you get a protocol startup... so you'd make your email login "email" with password (if any) "email". A PC could just start straight up with the protocol. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
sl@van-bc.UUCP (Stuart Lynne) (12/21/89)
In article <7375@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <8912200236.AA25652@ucbvax.Berkeley.EDU> cire@CISCO.COM (cire|eric) writes: >> Yes Computer based telecommunications has a great deal of more utility >> than FAX but I don't think that is the point. You must first make the >> connection before all that starts making a difference. > >OK. Let's do it. What should the communications look like? UUCP? Dial-up >SLIP? Or something more like FIDO? All we need to do is agree on a >standard and then we can start saying: > > mail 7134385018!peter >Or: > mail peter@7134385018.PHONE > >And folks with home PCs can do the same. Just make it simple enough that >any bozo with a copy of PCTalk can hack it up. > >Chat scripts for UUCP, and baud rates, are the biggest problem. > >How about this: > >To start up the session, you need to send the string "email<CR>". This should >handle the login problems. You keep sending this string with a 1 second >delay until you get a protocol startup... so you'd make your email login >"email" with password (if any) "email". A PC could just start straight up >with the protocol. A couple of suggestions. First anything you do shouldn't disenfranchise the existing successful base that is using fax technology. Your new protocol should be able to send "email" to a fax machine and receive and print a fax from a fax machine. Let's face it at this point in time you'll be able to send email to more destinations by simply doing this than anything else. Of course this implies that you'll need a V.29 modem and be able to support the T.30 protocols. This also simplifies to a certain extent what you do when your machine calls another or you answer the phone because the current specifications are pretty explicit. So what you do is work within the current standards committee's to make suggestions as to how these protocols can be extended to support sending/receiving messages/files. The end result is a pretty simple to use communications medium that will probably be quite successful because it leverages off of the current installed base of fax machines instead of competing against it. There are a couple of other interesting side effects. The cost of building V.29 modems is coming down. I've seen reports of $195 9600 bps fax modems. Definitely competitive with a 2400 Hayes compatible. A reasonable FTP using a 9600 bps fax modem can achieve something over 700cps throughput (wall clock timing on a file I watched being transferred). The current fax specifications have given us an specific way to place calls; synchronize with the far end; decide what type of operations will take place; at what speed; and can be extended for a wide range of other options. Other extensions could include higher signalling speeds, switching to a bi-directional 1200/2400 signalling mode for interactive use, etc. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
reggie@dinsdale.nm.paradyne.com (George W. Leach) (12/21/89)
In article <106@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >A couple of suggestions. >First anything you do shouldn't disenfranchise the existing successful base >that is using fax technology. Your new protocol should be able to send "email" >to a fax machine and receive and print a fax from a fax machine. I believe ATTMAIL provides this capability, and more..... I have heard that you will be able to broadcast a FAX message via a store and forward from ATTMAIL in the future (if not now). George W. Leach AT&T Paradyne (uunet|att)!pdn!reggie Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
eli@spdcc.COM (Steve Elias) (12/21/89)
>> cire@CISCO.COM (cire|eric) writes: >> Yes Computer based telecommunications has a great deal of more utility >> than FAX but I don't think that is the point. You must first make the >> connection before all that starts making a difference. fyi: commercial products which support email2fax are beginning to appear on the market. examples: the Bristol Group's product for Sun workstations, PC Research FaxIX (with a shell script or two). followups to alt.fax. -- { Steve Elias ; eli@spdcc.com ; 6179325598 ; 5086717556 ; } /* C */ { *disclaimer(); } /* not C */ { z = disclaimer(y) : (y = lim [x-->0] ( 1/x ) ) }
peter@ficc.uu.net (Peter da Silva) (12/22/89)
In article <106@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: > First anything you do shouldn't disenfranchise the existing successful base > that is using fax technology. Your new protocol should be able to send > "email" to a fax machine and receive and print a fax from a fax machine. I disagree. The main consideration should be to avoid disenfranchising the people currently using existing email systems. This should be something that someone with a PC and a $100 modem can hook into. This isn't intended to be an enhancement to FAX, but an enhancement to email: UUCP, SMTP, MCI-Mail, Compuserve, and so on. > Of course this implies that you'll need a V.29 modem and be able to support > the T.30 protocols. Which is why it's pretty much out of the question. These are relatively expensive modems and definitely complex protocols. This is out of reach of the majority of people who currently use email: individual computer hobbyists with PCs. And the end product can be built a LOT cheaper. An IBM-PC clone with a 1200 baud internal modem is in the few hundred dollar range. And then there are all the people with Commodore-64s. You're talking a complete system that costs less than a FAX modem alone. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
sl@van-bc.UUCP (Stuart Lynne) (12/22/89)
In article <7387@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <106@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >> First anything you do shouldn't disenfranchise the existing successful base >> that is using fax technology. Your new protocol should be able to send >> "email" to a fax machine and receive and print a fax from a fax machine. > >I disagree. The main consideration should be to avoid disenfranchising the >people currently using existing email systems. This should be something >that someone with a PC and a $100 modem can hook into. This isn't intended >to be an enhancement to FAX, but an enhancement to email: UUCP, SMTP, >MCI-Mail, Compuserve, and so on. I see, anyone with a $100 dollar modem can use any of these networks *right* now for just the cost of the phone call. Right. >> Of course this implies that you'll need a V.29 modem and be able to support >> the T.30 protocols. > >Which is why it's pretty much out of the question. These are relatively >expensive modems and definitely complex protocols. This is out of reach >And the end product can be built a LOT cheaper. An IBM-PC clone with a >1200 baud internal modem is in the few hundred dollar range. And then >there are all the people with Commodore-64s. You're talking a complete >system that costs less than a FAX modem alone. I've seen add's (maybe bogus, who knows) for $195 Fax Board plus software for an IBM PC. Well ok that's more than $100. But certainly less than your complete pc (generic) plus 1200 bps modem. With the introduction of the Yamaha Fax Chip I think you'll see a dramatic drop for these types of boards over the next two years. Up until recently Rockwell had a lock on the market and didn't have any real competition to force them to bring the prices down. What you seem to be proposing here is YAEFSMS (Yet Another From Scratch EMail Standard). What I'm suggesting is extending an existing successful standard. Specifically transferring RFC-822 compatible messages using the proposed Fax FTP standard. You want people to figure out a new set of protocols for connecting, establishing a common protocol, using a slow signalling technology, and start from scratch. A suggestion - might be easier to start with Fido stuff and work sideways. I want people to utilize an existing set of protocols for connecting and setting up the call, a faster signalling technology, and be able to hook into a very large and successful user base; with the addition of some simple mail transfer protocols to be used only when there is a computer at each end of the connection (ie no *real* fax machines). -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
peter@ficc.uu.net (Peter da Silva) (12/23/89)
In article <110@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: > I see, anyone with a $100 dollar modem can use any of these networks *right* > now for just the cost of the phone call. Right. Your sarcasm is noted. No, of course you can't. The whole point here is to change things so you can send mail to someone with no more than a phone number. But if this requires new hardware anyway, it should at least be cheap hardware. > I've seen add's (maybe bogus, who knows) for $195 Fax Board plus software > for an IBM PC. Well ok that's more than $100. But certainly less than your > complete pc (generic) plus 1200 bps modem. You can buy an Atari 800 for as little as $70. Commodore-64s are similarly priced. They're quite powerful enough to support this application. That gives you $130 for your modem. 1200 baud modems start under $100. There are millions of these cheap machines out there. Certainly more than FAXes. PLUS all the IBMs and IBM clones, many of which already have modems. > What you seem to be proposing here is YAEFSMS (Yet Another From Scratch EMail > Standard). You mean YAFSEM? No, I'm proposing a slight modification to UUCP. When someone has a FAX machine your proposal doesn't give me any additional capability. If they have an email machine then who cares whether it's FAX compatible or not. And as for the transfer speeds, my proposal has been demonstrated at up to 18,000 baud using Telebit Trailblazers. That's about twice as fast as FAX. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
sewilco@datapg.MN.ORG (Scot E Wilcoxon) (12/23/89)
I thought "Networks considered harmful" suggested generalizing message
connections so any caller could deliver mail to any callee.
I think that some messages are best delivered by text, some by graphics,
and some by voice. A "telephone" could answer with signals which tell
the calling "telephone" which types of messages can be handled, and the
local preference. The "telephones" can be connected to voice answering
machines, e-mail computers, fax machines, handsets (for "live" voice
calls), and other devices. Various translations (email to fax, email
to voice, etc) could be provided by "telephones" or connected devices.
Allowing uucico to be a front end for negotiating various protocols is
a step in the right direction, but before the uucico handshake there
should be another level of handshaking. This connection-making front
end must know what type of work needs to be done and what type of
connection has been made (the latter at present by a combination of
the type of device being used and the call progress messages from
the modem, such as "CONNECT 2400" or "FAX 9600"). By knowing the
type of work, the connection-making front end can decide whether
to start uucico or translate email to fax.
The connection-making front end could also handle connection
negotiations for smart "telephones", but some negotiation protocols
should also be defined for popular technologies. Specifically,
an asynchronous modem connection should begin with one or both
sides deciding what type of connection should be established (ie,
SL/IP, Zmodem, or uucico via a UNIX login).
--
Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco
Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco
I'm just reversing entropy while waiting for the Big Crunch.steve@nuchat.UUCP (Steve Nuchia) (12/24/89)
In article <7403@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >And as for the transfer speeds, my proposal has been demonstrated at up to >18,000 baud using Telebit Trailblazers. That's about twice as fast as FAX. Isn't it misleading to compare baud (actually, bit) rates for FAX and E-mail? One is sending an image, the other text. FAX has a lot of advantages, but text transfer efficiency isn't one of them. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "If the conjecture `You would rather I had not disturbed you by sending you this.' is correct, you may add it to the list of uncomfortable truths." - Edsgar Dijkstra
sl@van-bc.UUCP (Stuart Lynne) (12/24/89)
In article <17788@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: }In article <7403@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: }>And as for the transfer speeds, my proposal has been demonstrated at up to }>18,000 baud using Telebit Trailblazers. That's about twice as fast as FAX. } }Isn't it misleading to compare baud (actually, bit) rates for FAX and }E-mail? One is sending an image, the other text. FAX has a lot of }advantages, but text transfer efficiency isn't one of them. No it's fair. The suggestion is for extensions to the fax standards to support FTP using V.29/V.27 compatible modems. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
peter@ficc.uu.net (Peter da Silva) (12/26/89)
In article <24189@datapg.MN.ORG> sewilco@datapg.MN.ORG (Scot E Wilcoxon) writes: > Allowing uucico to be a front end for negotiating various protocols is > a step in the right direction, but before the uucico handshake there > should be another level of handshaking. Your solution depends on new hardware (FAX modems). The first stage needs to be something that can be implemented now, without changing code. Allowing anonymous UUCP with a standard account (email) and password (email) does this. Big systems will have to set things up manually, but PeeCees can run a slightly modified UUPC or GNUUUCP. If someone with the code and the time did it today (alas, I have neither), we could start sending messages tomorrow. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
jacob@gore.com (Jacob Gore) (12/27/89)
/ comp.protocols.tcp-ip / peter@ficc.uu.net (Peter da Silva) / Dec 26, 1989 / > Allowing > anonymous UUCP with a standard account (email) and password (email) does > this. I think we Unix system administrators have been doing this for so long, that we forgot that it's not "UUCP" that requires a login and a password. Just run uucico (or its equivalent) on the modem's port, instead of running a getty->login->uucico. > Big systems will have to set things up manually, but PeeCees can run > a slightly modified UUPC or GNUUUCP. Where is GNUUUCP? I tried to find it a few months ago, but could locate no trace of it. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
sl@van-bc.UUCP (Stuart Lynne) (12/27/89)
In article <670004@gore.com> jacob@gore.com (Jacob Gore) writes: >/ comp.protocols.tcp-ip / peter@ficc.uu.net (Peter da Silva) / Dec 26, 1989 / >> Allowing >> anonymous UUCP with a standard account (email) and password (email) does >> this. > >I think we Unix system administrators have been doing this for so long, >that we forgot that it's not "UUCP" that requires a login and a password. >Just run uucico (or its equivalent) on the modem's port, instead of running >a getty->login->uucico. I doubt that uucico would work properly without having it's environment setup by login. Might be able to fudge it with from inittab with script. Don't forget some systems (eg Xenix) don't easily allow anything but getty to run on a tty port. I suppose it would be possible, but not to obvious. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
peter@ficc.uu.net (Peter da Silva) (12/28/89)
[ standardising chat scripts: login email, no password, 8n1... ] In article <670004@gore.com> jacob@gore.com (Jacob Gore) writes: > I think we Unix system administrators have been doing this for so long, > that we forgot that it's not "UUCP" that requires a login and a password. > Just run uucico (or its equivalent) on the modem's port, instead of running > a getty->login->uucico. This is a problem for pre-SysV systems, which don't have an inittab so you can't have uucico run from init. Also, this requires that you dedicate a phone line to this function. I don't know about you, but I'd rather not do that. > [where do you get GNUUUCP] Check your comp.sources.amiga archives. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
jacob@gore.com (Jacob Gore) (12/29/89)
In article <670004@gore.com> jacob@gore.com (Jacob Gore) writes: > Just run uucico (or its equivalent) on the modem's port, instead of running > a getty->login->uucico. / comp.protocols.tcp-ip / peter@ficc.uu.net (Peter da Silva) / Dec 27, 1989 / > This is a problem for pre-SysV systems, which don't have an inittab so you > can't have uucico run from init. You don't need init. Let uucico run as a daemon, started from /etc/rc. Well, you may need an equivalent of a getty unless you standardize on a specific speed/parity/stop bits/etc. combination. > Also, this requires that you dedicate a > phone line to this function. I don't know about you, but I'd rather not > do that. I wouldn't either, but I thouht we were talking about turnkey point-to-point email, based on your generic Piece of Crap clones. Dialing out of from the computer could push aside the uucico on the port. All you'd lose by dedicating the port to uucico is being able to handle incoming calls that have nothing to do with email. If it's a PC, your average user won't be dialing into it... And if the call is received by a > > [where do you get GNUUUCP] > Check your comp.sources.amiga archives. Thanks. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
peter@ficc.uu.net (Peter da Silva) (12/29/89)
> You don't need init. Let uucico run as a daemon, started from /etc/rc. > Well, you may need an equivalent of a getty unless you standardize on a > specific speed/parity/stop bits/etc. combination. I wouldn't want to standardise on a speed. Use the fastest hardware you can afford. And if you need getty, why not? > I wouldn't either, but I thouht we were talking about turnkey > point-to-point email, based on your generic Piece of Crap clones. Yeh, but I'd like to keep it compatible with existing point-to-point UUCP. So you can have your UNIX mini in the office accept calls from the salesemen and feild engineers laptop email machines. So a *simple* standard chat script would be handy. "" ogin--ogin--ogin email for a PC: send "CR" until you get "login", then send "emailCR" until you get a protocol start. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com