DIXON-R@OSU-20.IRCC.OHIO-STATE.EDU (Bob Dixon) (10/11/89)
This is a pre-announcement of a Fax over tcp/ip package we now have operational
here in prototype form, and which will be made available free to educational
institutions when it is finished and polished up.
The basic scheme is to use a PC clone as a network gateway (total hardware
cost for PC is $2K). A fax card is used in the PC to communicate with a
co-located conventional group 3 fax machine. The fax machine thinks it is
using a telephone line to call some distant fax machine, but in fact it is
just talking to the PC. The PC stores the fax data as a binary file. The PC
then uses binary FTP to send the fax file out its ethernet port to any similarly
arranged system anywhere in the Internet, where the process is reversed.
The FTP portion of the operation is essentially instantaneous in comparison
with the normal time needed by the fax machine to scan a document.
A scanner and graphics printer can be used instaed of the local fax macine if
desired. Both the fax machine and PC may also be used for other tasks if
desired, and need not be dedicated solely to this function.
It is not terribly difficult to assemble such a system, and to operate it in
a crude manual mode. We have it operable in a somewhat automated mode now,
and are working on the necessary software to make it robust, error-tolerant
and very user-friendly so that it can be used as a routine tool by people
such as librarians. There is great need for such a capability among libraries
for inter-library loan.
When the software is finished it will be distributed free to anyone who
wants it, along with a suggested hardware configuration.
Bob Dixon
Ohio State University
-------eli@spdcc.COM (Steve Elias) (10/11/89)
will we see complaints about fax files using too much bandwidth on
the internet? the service i offer is not used very often, and only
transfers small text files when it is used. i am reluctant to offer
the reverse service, as the gentleman from ohio state has just offered.
an average fax page is about 20k or 30k... i've been wondering if
people (site admin cats) would complain if the internet were used
routinely to transfer fax files around... what do you think?
--
... Steve Elias (eli@spdcc.com);6178906844;6179325598; {}
/* email2fax! send email for info */WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (10/13/89)
Steve, Perhaps it would be reasonable to pre-ftp compress, post-ftp uncompress these files? Always send out out compressed files and toss received files which won't uncompress with a rejection notice. --Frank
almes@RICE.EDU (Guy Almes) (10/13/89)
Steve, The Internet consists of a large fabric of (increasingly) T1 leased lines to be used in support of scholarship and research. If we use it to ship FAX images, and if those images support scholarship and research, and if they comprise a small fraction of our (fixed cost) circuits, then I don't think there would be objection. One positive outgrowth would be that, if this became common, then people would start building interesting/useful tools, including: * compression techniques for reducing the bandwidth required, * more flexible inputs than simple scanners (various text or graphic format files as input) * more flexible outputs than FAX printers besides, it might spur real use of multimedia mail if/when our multimedia mail techniques are shown to be better. I'm not a fan of FAX, but it is useful at times and there is no reason to be stuck with dial up phone lines when we do use it. -- Guy
eli@URSA-MAJOR.SPDCC.COM (10/13/89)
hello Frank, group 3 fax files are already compressed by both run length and huffman coding, so unix LZ compression isn't apt to provide much more compression... steve ------- Forwarded Message In-Reply-To: Msg of 11 Oct 1989 07:53-MDT from spdcc!eli at bloom-beacon.mit.edu (Steve Elias) Steve, Perhaps it would be reasonable to pre-ftp compress, post-ftp uncompress these files? Always send out out compressed files and toss received files which won't uncompress with a rejection notice. - --Frank ------- End of Forwarded Message
eli@URSA-MAJOR.SPDCC.COM (10/13/89)
hello Frank, group 3 fax files are already compressed by both run length and huffman coding, so unix LZ compression isn't apt to provide much more compression... steve ------- Forwarded Message In-Reply-To: Msg of 11 Oct 1989 07:53-LDT from spdcc!eli at bloom-beacon.mit.edu (Steve Elias) Steve, Perhaps it would be reasonable to pre-ftp compress, post-ftp uncompress these files? Always send out out compressed files and toss received files which won't uncompress with a rejection notice. - --Frank ------- End of Forwarded Message
702WFG@SCRVMSYS.BITNET (bill gunshannon) (10/14/89)
Considering the fact that we can already Email graphic images over TCP/IP,
why would anyone want to step backwards to low resolution black&white FAX
pictures???
bill gunshannon
702WFG@SCRVMSYS.BITNEThd@kappa.rice.edu (Hubert D.) (10/14/89)
I suggest using the CCITT group 4 document transmition standard instead of the CCITT group 3 specification which is used over the phone lines. The group 4 spec uses ONE compression table for the entire file; group 3 uses a compression table for EVERY line. The internetwork is a much more reliable medium than the telephone lines. So, a protocol which suits the medium should be used --==-- Hubert Daugherty Department of Electrical and Computer Engineering hd@rice.edu Rice University (713) 527-4035 Houston, TX 77252
karl@asylum.SF.CA.US (Karl Auerbach) (10/14/89)
In article <8910131208.AA18264@iapetus.rice.edu> almes@RICE.EDU (Guy Almes) writes: >Steve, > The Internet consists of a large fabric of (increasingly) T1 leased >lines to be used in support of scholarship and research. If we use it >to ship FAX images The X.400 mail system can take fax images, both group 3 and group 4 (as well as voice, executables, ... and even ASCII text). (For the TCP/IP "purist" [such a euphamism!], X.400 could be considered a child of the TCP/IP community as it came from IFIP WG6.5 before ISO/OSI got 'hold of it.) Marshall Rose has demonstrated that X.400 can work over TCP/IP. We ought to avoid inventing yet another protocol just to handle FAX. --karl--
sl@van-bc.UUCP (Stuart Lynne) (10/14/89)
In article <2078@brazos.Rice.edu> hd@rice.edu (Hubert D.) writes: >I suggest using the CCITT group 4 document transmition standard instead >of the CCITT group 3 specification which is used over the phone lines. The >group 4 spec uses ONE compression table for the entire file; group 3 >uses a compression table for EVERY line. The internetwork is a much >more reliable medium than the telephone lines. So, a protocol which >suits the medium should be used The problem is not so much that you want to choose *ONE* bit encoding spec, but that you are probably going to have to support several. There is a basic tradeoff to make. If we choose one standard (eg G3 or G4) then you will have to convert whatever you have to that standard. This involves CPU cycles. If you allow multiple standards (ie G3 and G4) then all sites will have to support multiple formats, but you won't have to convert from what you have to a standard format if the other end does understand what you already have. This may involve extra communications bandwidth but may conserve CPU cycles at each end. I would suspect that if a fax transfer standard is implemented it should involve a handshake at the beginning where each end tells the other what it understands. Then if you have a format which the other end doesn't understand you know you have to convert before sending otherwise you just send it. We store fax images in TIFF files and support G3, packbits, Lempel-Ziv and will be doing G4 shortly. Right now we're leaning towards Lempel-Ziv. It gives similiar compression ratio's to G3 and is much faster to do (ie less CPU cycles). For colour images it's better than G3. -- Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
CERF@A.ISI.EDU (10/15/89)
If you FAX IN to your PC, how does it figure out where to send the file via FTP? Or convey to the far end what fax number to call to deliver it? Or have I confused the service functionality? Vint
eli@spdcc.COM (Steve Elias) (10/15/89)
In article <[A.ISI.EDU]15-Oct-89.10:30:31.CERF> CERF@A.ISI.EDU writes: >If you FAX IN to your PC, how does it figure out where to send the >file via FTP? Or convey to the far end what fax number to call >to deliver it? Or have I confused the service functionality? > >Vint hi Vint! nice rap on gigabit networking at interop! i surely won't complain about wasting bandwidth on fax, ok? the two questions... 1 -- how to specify the destination fax number for the email2fax direction? grepping the subject line or some such scheme is a simple solution. 2 -- how to specify the destination email address from an inbound fax? this is the more interesting question, i think. the bruteforce way to deal with inbound faxes to standard phone lines on PCs or other unix systems is to have some sort of character recognition and a standard for where (or how) to write/print the destination email address... i needn't explain the difficulties with such a scheme, however. the reliable method is to use DID phone lines and DID capable PC-fax cards in the fax2email server PCs. such phone lines are a bit expensive -- $100 per month per 100 phone numbers, with some additional charges for the number of trunks. for those who aren't familiar with DID (Direct Inward Dial) -- it is the method the phone company CO uses to transmit phone numbers down to big PBXs and other automated phone equipment. (such as voice mail.) each 'subscriber' to the fax2email service could have a specific fax phone number assigned. simple database lookup in the fax2email server could provide the proper email destination address for the fax. the only chance for misdelivery would be if the source fax hardware dials the wrong phone number. (DID numbers are assigned in big blocks, as in 555-5400 to 555-5599). -- ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {} /* free email2fax! send email for info. */ /* be rude to a headhunter today and win free prizes! */
karn@ka9q.bellcore.com (Phil Karn) (10/16/89)
In article <254@ursa-major.SPDCC.COM> eli@ursa-major.spdcc.COM (Steve Elias) writes: > the reliable method is to use DID phone lines and DID capable > PC-fax cards in the fax2email server PCs. [..] Yes, this technique works, but it sure has an appetite for telephone numbers! Bellcore is the entity charged with the administration of the North American Numbering Plan; they're the ones who assign new area codes as needed to meet demand for telephone numbers. Given the rate at which area codes have been splitting over the past few years (leaving only a handful of unused codes) I wouldn't be surprised to see some eyebrows raised in certain circles around here at yet another proposed large-scale consumer of telephone numbers. Particularly since they're only needed to overcome a limitation of the existing G3 FAX protocol (i.e., the inability to specify a recipient.) In any event, I suspect the skyrocketing demand for cellular phones, pocket pagers, (real) fax machines and computer modem lines are all going to force *some* sort of resolution to the crisis in the next few years... Phil
gnu@hoptoad.uucp (John Gilmore) (10/19/89)
sl@van-bc.UUCP (Stuart Lynne) wrote: > I would suspect that if a fax transfer standard is implemented it should > involve a handshake at the beginning where each end tells the other what > it understands. Then if you have a format which the other end doesn't > understand you know you have to convert before sending otherwise you just > send it. Clearly what we want on the Internet is more like what computer fax over phone lines should be doing (except that the designers of fax didn't think about extensibility, and the people who implement it are too busy (hacking slimy binary MSDOS software) to support real computers or consider the larger issues). You should hand it a document in ANY format; it sends it to the recipient in the recipient's choice of format. E.g. you hand it troff source; if the recipient can handle troff source, it gets sent that way; backoffs to ditroff intermediate form, PostScript, MacDraw, HPGL, bitmaps, G3 and G4 fax, etc, are all possible depending on what the recipient can handle. This has to be negotiated separately for each recipient, since one could be a phone-fax relay service and another a window system or something. Note that data modems have the same sort of problem: when answering a call, the two modems need to negotiate to decide what mutually agreeable protocol will be used over the line. Current modems use a horrid solution: try one, wait a while, try another, ... burning billable time at your expense. A better solution would have been to send a burst of touchtone digits, each digit pair or triple indicating a supported protocol. The other side would send its best choice among them and it all happens in a second or two. (This protocol is stolen from the uucp startup sequence.) For tcp/fax negotiations I'd define a standard set of format names in ASCII, rather than using numeric codes; it's easier to use and extend a set of names. Also, we probably want to send more information during the negotiation, like the file name and size, sender's identification, etc, so the recipient can use the info in deciding what format to request (e.g. if I know that I get a message weekly from you, and it works best in PostScript, I can set up to request PostScript from you even though you are supplying it in TeX). -- John Gilmore {sun,pacbell,uunet,pyramid}!hoptoad!gnu gnu@toad.com "Watch me change my world..." -- Liquid Theatre
eli@spdcc.COM (Steve Elias) (10/19/89)
In article <8734@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >Clearly what we want on the Internet is more like what computer fax >over phone lines should be doing (except that the designers of fax >didn't think about extensibility, and the people who implement it are >too busy (hacking slimy binary MSDOS software) to support real >computers or consider the larger issues). i won't argue with you regarding the slimosity of DOS... but you are wrong that nobody is worrying about supporting real computers and addressing the larger issues. these things are happening at MANY companies out there. nobody appears to have announced anything yet, though. -- ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {} /* free email2fax! send email for info. */
CURT.ELLMANN@MAIL.ADMIN.WISC.EDU (11/08/89)
Comment: Processed by UWGATE to: tcp-ip@nic.ddn.mil Several weeks ago (?) there was a bit of activity on this group about exchanging FAX data streams over TCP/IP networks. Is anyone doing this now? Are there any plans to do this sort of thing? Surely *someone* is working on an RFC, right? I would sincerely appreciate any leads. Thanks. -curt. curt.ellmann@mail.admin.wisc.edu ?
DIXON-R@OSU-20.IRCC.OHIO-STATE.EDU (Bob Dixon) (11/09/89)
We are now doing this, and are developing a user-friendly interface to allow
routine use of the system for interlibrary loan at the Big 10 school
libraries. We will distribute it freely to all when it is ready to go.
For details, contact Bob Debula (bobd@hpuxa.ircc.ohio-state.edu).
Bob Dixon
Ohio State University
-------brian@ucsd.Edu (Brian Kantor) (11/10/89)
I've developed a cute little hack that adds email->fax capability to sendmail. It uses a slave PC with a FAX card in it to do the actual conversion and transmission. I sent it to rsalz for publication in comp.sources.unix, so watch for it there if you're interested. - Brian
gardner@ux1.cso.uiuc.edu (11/10/89)
Here at the University of Illinois, Computer Services Office, I am working on an email to fax(and eventually the other way) program. I have a Zenith '386 with an Intel CCP fax board. It also has PC-nfs and Lifeline. Lifeline allows me to retrieve mail with a "pop2" command and send it with a "smtp". A C program(under construction) will retrieve mail from a fax signon, strip related (user-supplied) headers and send the fax. Oh, yea and do appropriate accounting. Users can receive reply mail when the fax is sent off. For retrieving, I have a commercial package which can convert Intel's PCX format to postscript, gif, tiff and a dozen more. I have hopes for a process something like this: Fax is recieved. Operator pulls up cover page on screen(Intel has an integrated viewing program which lets you slide up and down the pages. Operator sends email to person(s) listed on fax(using our campus electronic phone book) or simply calls them up. The fax is stored under this name for later retrieval. Recipient informs operator how he wants to receive fax - options: Print out and drop in campus mail( we are engaged in a program to provide Email address for all students and academic staff) Print out on CSO printer and recipient picks up. Send to campus printer nearest recipient. (We have a developing Network Print Service). Transcribe the document and send email, with paper copy of fax to follow in email.(most people say yeeccchhh on this one). make file available for direct retrieval by recipient - in his format, postscript, gif, tiff etc. via FTP, email/uuencode etc. Dreams - OCR to read recipient address and or document - however from the faxen I've seen, this is a long way off. mgg ************************************************************************ * * * * * * CCC SS OO * * *+ + C S O O * * ** + C S O O * * +* *+ CCC SS OO * * + ** * * + +* University of Illinois, Computer Services Office * * * * 1304 W Springfield, Urbana, Il 61801 * * * Michael G. Gardner, Assistant Director, 173 DCL * * (217)244-0914 gardner@ux1.cso.uiuc.edu * * FAX 244-0916 * ************************************************************************
hlison@bbn.com (Herb Lison) (11/14/89)
gnu@hoptoad.uucp (John Gilmore) writes: >Clearly what we want on the Internet is more like what computer fax >over phone lines should be doing (except that the designers of fax >didn't think about extensibility, and the people who implement it are >too busy (hacking slimy binary MSDOS software) to support real >computers or consider the larger issues). You should hand it a >document in ANY format; it sends it to the recipient in the recipient's >choice of format. E.g. you hand it troff source; if the recipient can >handle troff source, it gets sent that way; backoffs to ditroff >intermediate form, PostScript, MacDraw, HPGL, bitmaps, G3 and G4 fax, >etc, are all possible depending on what the recipient can handle. This >has to be negotiated separately for each recipient, since one could be >a phone-fax relay service and another a window system or something. Another alternative to FAX on the Internet, or networks in general, is multimedia E-mail. BBN/Slate is a product that allows the user to e-mail documents containing text, graphics, spreadsheets, images (color, as well as black and white), and even digitized voice, over standard text mail systems, such as sendmail, MMDF. Of course, for those users without high performance workstations, FAX is still a good way of getting multimedia material (albeit without the capability of doing much more than looking at it), and we are implementing a FAX handling capability in Slate. Anyone interested in getting more information can look in the October issue of UNIX Review. Herb Lison
eli@spdcc.COM (Steve Elias) (11/23/89)
>gnu@hoptoad.uucp (John Gilmore) writes: > >>Clearly what we want on the Internet is more like what computer fax >>over phone lines should be doing (except that the designers of fax >>didn't think about extensibility, and the people who implement it are >>too busy (hacking slimy binary MSDOS software) to support real >>computers or consider the larger issues). John's generalization about "the people who implement fax" is clearly incorrect. computerfax under actual operating systems is available. and some computerfax designers are thinking about larger issues, as well as real computers! -- ... Steve Elias ; eli@spdcc.com ; 6179325598 ; {} *disclaimer(); /* watch out for litigous pinheads! */ /* and: free email-->fax for boston destinations */