HDTenEightyP/NetNews huggingface dataset:
From: cikan@edwin.par.univie.ac.at (Edwin Cikan)
Subject: Netfax with SUNOS 4.1.2
Keywords: netfax,sunos,problems
Reply-To: cikan@par.univie.ac.at
Organization: University of Vienna
Date: Fri, 4 Sep 1992 14:00:22 GMT

Hi,

I just subscribed to this newsgroup and I don`t know if this questions
were already discussed here. I tried to install netfax 3.2.1 on our SUN network,
but I was not able to make it work. I cannot find out every information I need
from the readme-files. I didn`t find any doc files also. The installation
description is not very helpful (for me).

The faxhost is a SUN ELC with SUNOS 4.1.2, and the modem is a ZyXEL U-1496E.
If I want to send a fax, nothing is spooled. When I try to receive a fax,
the modem answers, but the faxspooler does nothing at all. 

Is there anyone who was able to install and run successfully netfax on SUN
Systems? If yes, could this one be so kind to give me some hints?

I would like informations about any faxsoftware for SUN Systems too.

Thank you all in advance,

-- 
Edwin CIKAN
Systems Administrator

University of Vienna
Department for statistics and computer science
Bruenner Strasse 72
A-1210 Vienna, Austria (EUROPE)

e-mail: cikan@par.univie.ac.at (Internet)
Tel.:   +43 1 392647-206

Newsgroups: comp.dcom.fax,comp.dcom.modems
From: tdyck@fraser.sfu.ca (tReVoR)
Subject: External Fax/modems
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Fri, 4 Sep 1992 18:03:41 GMT

I am looking for EXTERNAL fax/modems which give an RS-232 output to the
computer.  I will not be using any standard fax software, I will be writing
my own as this is for a specific application.

Does anyone have a list of external fax/modems?  If not, could
you please direct me to a list of this type (ie. in a magazine, or on
an ftp site somewhere).

The only ones I have been able to find are the Zoom faxmodem and the 
US Robotics 9624.

Any help is greatly appreciated.

Thanks,

Trevor Dyck				internet: dyck@mprgate.mpr.ca
Advanced Technology Division
MPR Teltech Ltd.
Burnaby, B.C., Canada


Newsgroups: comp.dcom.fax
From: jhpb@sarto.budd-lake.nj.us (Joseph H. Buehler)
Subject: Re: Ghostscript 2.5 (dfaxlow) images
Followup-To: comp.dcom.fax
Organization: none
Date: Thu, 3 Sep 1992 01:25:35 GMT

In article <moyman-020992144641@jonathan.ecn.purdue.edu> moyman@ecn.purdue.edu (Mike Moya) writes:

   Messing around with this device seems to create an image that doesn't seem
   quite right. I used it on a full page PS image, the result was an image
   only half (vertical) the size of the original but at the same time the same
   width? The result is the image looks smashed. Is this how it's suppose to
   look? I was expecting a full page size image only not as good resolution?
   The command used was something like: 

   gs -sDEVICE=dfaxlow -sOUTPUTFILE=file.g3.low file.ps

The "low" resolution G3 has half the resolution in the vertical
direction that it does in the horizontal.

It sounds like you tried to print it as if it had the same resolution
in both dimensions.  This would result in the "smashed" image you
mention.
Newsgroups: comp.dcom.fax,comp.dcom.modems
From: kak@hico2.westmark.com (Kris A. Kugel)
Subject: Re: wherefor NetFax? (was HELP! Netfax 3.2 on SVR3.2
Reply-To: kak@hico2.westmark.com
Organization: High Country Software
Date: Thu, 27 Aug 1992 03:35:14 GMT

: Be advised, though, that this software is nowhere near release-level
: code, and installing is not going to be anywhere near plug-and-play.

	Certainly for us SysV.2 folk.

: There is almost zero documentation on how to set it up; the code is
: littered with numerous BSDisms and other porting nightmares; and the
: makefiles are very poorly written.

: In short, the software
: distribution looks more like a source tree snapshot than it does a
: software release.
: 
: -- 
: Marc Unangst              
: mju@mudos.ann-arbor.mi.us  
:                             

	I'm not so sure about the makefiles.  In particular,
	they are set up assuming gnumake, so I can't say exactly
	how well they are written for that environment.

	I *WAS* able to get the makefiles to work more-or-less
	as intended with only a little modification for Sys V.2 Make.
	UNIX lets you do just about anything if you're jerk enough
	to waste the time to learn it and do it.
	The only loss is the automagic library generation, which
	means you have some extra .o's sitting around during the Make process.

	Anyhow, the BSDisms seem to be the critical factor.  If anybody
	out there wants to tackle MAJOR cross-system porting, I'll send
	you the altered Makefile.

	I dunno, this package could be pretty useful for me,
	but I'm not willing to spend the (25? 40?)-or-so hours
	it would take me to get it understood, ported, and solid
	on my *mostly* System V.2 3B1.  (a damn BSD unix manual
	would help.)  AND buy a fax modem on the assumption
	that I'll get it working.   It might be worth it as a
	group effort once some of the early-release bugs are
	worked out of it.  I'm starting to think it'd be
	worthwhile to get a new machine just to avoid these
	system-related kind of problems.

Kris A. Kugel	908-842-2707
hico2!kak	kak@hico2.westmark.com
Newsgroups: comp.dcom.fax
From: tdyck@fraser.sfu.ca (tReVoR)
Subject: What is Class1/Class2?
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Wed, 2 Sep 1992 18:06:33 GMT

Can someone please tell me what Class 1 and Class 2 fax is?  What is the
difference between these?  Are they both Group 3 fax?

Also, is there a FAQ list for this newsgroup?  I have been following this
group for a while and haven't seen one.

Any help is GREATLY appreciated.

Trevor Dyck
Advanced Technology Division
MPR Teltech Ltd.
 
dyck@mprgate.mpr.ca
Newsgroups: comp.dcom.fax
From: ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks)
Subject: Supra FaxModem answer Modem/Fax mode
Organization: Innovative Concepts
Date: Wed, 2 Sep 1992 04:33:03 GMT

Is there a way to get a supra modem to answer in both fax and
modem mode(i.e., I want to write a program like getty that sits
and talks to the modem.  If a call comes in, I want it to be 
able to destinguish between a fax call and a modem call.  What
provisions for this, if any, are provided in the supra command set?

I've tried talking to supra tech support but all they tell me is to go
get such and such document.  Its not like I'm asking for that much....
From: lchiu@animal.gcs.co.nz (Laurence Chiu)
Newsgroups: comp.dcom.fax
Subject: Re: HELP WANTED: Fax Software for MS-DOS/Windows
Date: 30 Aug 92 22:27:32 GMT
Organization: GCS Limited, Wellington, New Zealand

In article <1992Aug29.205257.15614@sfu.ca> vary@fraser.sfu.ca (Jason Vary) writes:
>Hello all-
>
>   I recently bought a Supra 14.4k Fax/Modem.  No fax software came
>with it, and I was wondering which is the best software to
>send/receive faxes with?  It would be for an MS-DOS machine running
>under DOS or Windows. 
>   Here are the specs for the Fax:
>     14400/12000/9600/4800/2400/1200/300 bps send/receive
>     Class 1 & 2 commands
>     Compatible with Group 3 Fax Machines
>     V.17, V.29, V.27
>
>   Any help would be greatly appreciated.
>
>seeya
>jason
>--
>vary@sfu.ca

Try winfax Pro 2.0 for Windows or Winfax Pro for DOS. I can't vouch for
the second but I have nothing but praise for the first. Plug and play
usually. BTW I use it on a Boca 14.4 V32bis fax/modem with no problems.

Laurence Chiu
Newsgroups: comp.dcom.fax
From: berger@atropa (Mike Berger)
Subject: Re: Needed: Fax2gif
Organization: University of Illinois at Urbana
Date: Fri, 28 Aug 1992 00:42:27 GMT
Keywords: fax2gif,gif

cmbecker@casbah.acns.nwu.edu (Canton Becker) writes:
>	I'm having a terrible time trying to get received faxes from the
>Trufax package to print or display...  Does anyone know how I can convert raw
>fax files to gif format?  (I need to look at these on a Sun, if there are any
>other ideas.)
*----
I believe that Hijaak, a commercial program for the PC, will do that.
--
	Mike Berger
	Department of Statistics, University of Illinois
	AT&TNET     217-244-6067
	Internet    berger@atropa.stat.uiuc.edu
Newsgroups: comp.dcom.fax
From: cjc@casbah.acns.nwu.edu (Christopher Chen)
Subject: FlexFax?  Comm-Server?  Huh?
Organization: Northwestern University
Date: Mon, 31 Aug 1992 18:43:24 GMT

I've got these people here who employed a consultant who isn't around
anymore (for various reasons, he didn't leave things behind and they
don't want to pursue him), and he bought them a FlexFax fax/modem and
a demo version of Comm-Server.

Has anyone heard of these two?  I'm vaguely familiar with most Mac
products, but I've *never* seen either of these.


Any help I can get would be appreciated.


cjc
--
Christopher J. Chen  cjc@nwu.edu  (708) 491-4109  (708) 491-3824 fax
Academic Computing and Network Services, Northwestern University
"Do not try to solve all life's problems at once -- learn to dread each day 
 as it comes."				-- Donald Kaul
-- 
Christopher J. Chen  cjc@nwu.edu  (708) 491-4109  (708) 491-3824 fax
Academic Computing and Network Services, Northwestern University
"Do not try to solve all life's problems at once -- learn to dread each day 
 as it comes."				-- Donald Kaul
Newsgroups: comp.dcom.fax
From: rpg@world.std.com (r goldsmith)
Subject: "Hands-off" Fax software
Organization: The World Public Access UNIX, Brookline, MA
Distribution: n.a.
Date: Mon, 31 Aug 1992 14:48:55 GMT


I'm looking for a fax s/w package that can be run "hands-off".

I need to be able to set up a system that will simply print every
incoming fax.  It doesn't have to do much else.  It would run on a
cheap DOS clone (and that machine would be dedicated to just receiving
and printing faxes.

Any ideas?

reply to rpg@world.std.com
Newsgroups: comp.dcom.fax
Subject: Supra bug description?
From: olof@ida.dsir.govt.nz (Olof Olsson)
Date: 3 Sep 92 08:00:52 GMT
Organization: DSIR/IDA Auckland, New Zealand

I read the announcement about the new Supra V32bis ROMs the other
day, that promises to fix a bug that causes the modem to not being
able to connect to some fax modems. Has anybody run into this problem?

If you have, could you please describe what remote fax machine it
failed to connect to and in what way the connection failed?

I have had some problems with GNU Netfax and the Supra V32bis modem
that caused the remote fax machine to issue a "FHNG: 52" for some
uknown reason. I am trying to figure out if this problem indeed is
the bug mentioned in the announcement. If it is, I can stop looking
for other ways of fixing it!!

Thanks,
	Olof


--
Olof Olsson                                               Machine Vision Team
E-mail: olof@ida.dsir.govt.nz                         Industrial Research Ltd
Phone: +64 9 303 4116, Fax: +64 9 307 0618              Auckland, New Zealand
Newsgroups: comp.dcom.fax
From: sergio@techunix.technion.ac.il (& Fogel)
Subject: International SureFax
Organization: /staff/023/sergio/.organization
Date: Sun, 30 Aug 1992 19:49:48 GMT

Does anybody have any information about International Surefax service?
I would like to know which countries are supported (both for sending
and receiving), and how to contact them. Any information will be greately
appreciated. 

Sergio Fogel
--
 Sergio Fogel
 sergio@techunix.BITNET
From: tnixon@hayes.com
Newsgroups: comp.dcom.fax
Subject: Re: What is Class1/Class2?
Date: 3 Sep 92 12:01:53 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Sep2.180633.4208@sfu.ca>, tdyck@fraser.sfu.ca
(tReVoR) writes: 

> Can someone please tell me what Class 1 and Class 2 fax is?  What is the
> difference between these?  Are they both Group 3 fax?

Class 1 and Class 2 are both extensions to the Hayes AT command set 
for modems, which support fax capabilities in modems.

Class 1 is defined in TIA-578 (a published standard).  It includes 
the minimal level of hardware support in the modem, with all of the 
fax protocols and image handling being done in PC software.

Class 2 is not yet an adopted standard. Modems on the market today 
claiming to be "Class 2" are based on an obsolete, cancelled first 
draft of the standard known as SP-2388 from August, 1990; when the 
real standard is adopted (hopefully, within the next few weeks!) it 
will be known as TIA-592.  Class 2 moves more of the fax protocol 
handling into the modem to offload the PC software, but the image 
handling remains in the PC.

Class 1 and 2 devices are always Group 3.

-- 
Toby Nixon, Principal Engineer      | Voice   +1-404-840-9200  Telex 401243420
Hayes Microcomputer Products, Inc.  | Fax     +1-404-447-0178  CIS   70271,404
P.O. Box 105203                     | BBS     +1-404-446-6336  AT&T    !tnixon
Atlanta, Georgia  30348             | UUCP uunet!hayes!tnixon  Fido   1:114/15
USA                                 | Internet                tnixon@hayes.com
Newsgroups: comp.dcom.cell-relay
From: robelr@ucs.indiana.edu (Allen Robel)
Subject: Re: Something New
Reply-To: robelr@mythos.ucs.indiana.edu
Organization: Indiana University
Date: Fri, 28 Aug 1992 19:47:17 GMT

In article <1992Aug28.154623.1160@iscnvx.lmsc.lockheed.com>  
bantha.decnet.lockheed.com!young writes:
> In-Reply-To: <BtLKKH.CJ6@usenet.ucs.indiana.edu>
> 
> Excerpts from netnews.comp.dcom.cell-relay: 26-Aug-92 Re: Future of IP
> routers by Allen Robel@ucs.indiana. 
> 
> >> Which means that the filtering functionality currently available
> >> in routers gets pushed out to end nodes and is carried out
> >> at call setup?  I'm not sure that I'm comfortable with this
> >> sort of arrangement. 
> 

Yes, I wrote the above...

> Using ATM to support customer premises routers, and value added network
> routers seems just fine.  What's the debate here?  Who cares if Ma
> Bell doesn't install routers in the ATM network, as long as we have
> value added networks to do it for us?
> 
> >Remember that ATM is going to replace the voice network as well as the
> >data network.  Take a look at call screening and call control in  
today's
> >voice networks; it is actually quite sophisticated.  In an ATM world,
> >the local ATM switch--acting much like today's PBX--will no doubt be
> >able to do all kinds of policy restrictions.
> 

But, no I didn't write this...

--
Allen Robel                      robelr@mythos.ucs.indiana.edu
University Computing Services    ROBELR@IUJADE.BITNET
Network Research & Planning      voice: (812)855-7171
Indiana University               FAX:   (812)855-8299
From: rasp@xlnt.com (Ron Perloff)
Newsgroups: comp.dcom.cell-relay
Subject: Re: >>>>Future of IP routers
Date: 1 Sep 92 16:43:37 GMT
Organization: xdi

In article <p9k3qsc@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon
Schryver) writes:
>That's a lot of confusing words to describe something that is obvious
>with a few diagrams.  It is a surprising notion, that every TRT
>expiration implies a "wasted, deadhead" rotation of the token around
>the ring.

Vernon is absolutely right, including the part about drawing some diagrams
to convince yourself.

A very convenient way to model this is to assume a 'dummy' node
in the ring that transmits a frame of length equal to the latency on every
rotation of the token. This helps visualize the performance implications
of some of the configuration parameters.

E.g., When you lower TTRT, you force more token rotations in any given
period of time and, therefore, the 'latency node' burns more bandwidth.
In a ring with a lot of latency, the amount of lost bandwidth may surprise you.

Ronald S. Perloff     rasp@xlnt.com
XLNT Designs, Inc.  (XDI)
15050 Avenue of Science
Suite 106
San Diego, CA  92128
619 487 9320   -   FAX: 619 487 9768
Newsgroups: comp.dcom.cell-relay
From: george@hal (George Marshall)
Subject: Re: Bare Bones Adaptation
Organization: ADAPTIVE Corporation
Date: Wed, 2 Sep 1992 04:33:25 GMT

>I have a question on the "lean mean" AAL5 adaption layer:
>
>Does this definition cover only the begin and end of message 
>indication, leaving the byte count and checksum to be handled
>by the application specific upper layer?  
>
>For instance, let's say I am collecting arbitrary uncompressed audio 
>from a continous source. With this application, I really have no checksum 
>requirement, no message boundaries, just collect bytes.
>
>Is this the bare bones adaption layer? 

For a continuous bit stream source as you described, there are other
(simpler?) adaptation layers defined/contemplated:

AAL1 (Class A) is a "Constant Bit Rate" AAL; this AAL is intended for 
use in emulating a real (as opposed to virtual) circuit service; 
there are no packet boundaries, and the primary function of this AAL 
is to provide sufficient information to allow the bit stream timing 
to be re-created at the destination (necessary since there will have 
been some jitter as the cells moved through the network.  The 
definition of AAL1 is about complete.

AAL2, (Class B) which is in a less mature definition state, is 
intended for Variable Bit Rate (VBR) services, in which the data 
stream is still a bit stream, but the data rate is not constant; an 
example of the use of VBR services would be compressed voice or 
video, in which there is some nominal maximum rate, but due to 
silence or good compression, there may be less than the nominal 
channel max.

George

---
George Marshall / george@adaptive.com / Voice 415-780-7727 / Fax 415-364-0123
ADAPTIVE Corp.  / 200 Penobscot Drive / Redwood City, CA  94063
Newsgroups: comp.dcom.cell-relay,comp.dcom.lans.fddi
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: Future of IP routers
Organization: Basket Weavers, Inc.
Date: Mon, 31 Aug 1992 01:33:41 GMT

In article <1992Aug28.092320.17105@ccsun.strath.ac.uk> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:

	I haven't seen a response to this, so I'll post...

>The point I am trying to make is that IP is 
>designed to route packets, and by route I mean
>direct the packet to the next router on it's 
>journey. Functionality of the ATM layer seems to
>perform the same function (substitute 'ATM' for 'IP', 
>'cells' for `packet` and 'switch' for 'router' 
>in the last sentence)
>and hence there is a wasteful overlap in 
>functionality when you have to reassemble 
>at each intervening router for router software to process. 

Well, there is and there isn't (a wasteful overlap). IP was designed
to route primarily between separate (and/or different) physical layer
technologies. For various reasons routing gets done on a per-packet
basis, etc, etc. However ATM should, in reality, be seen as primarily
another physical layer packet transport mechanism. Routing in the
ATM sense does not actually occur on a cell by cell basis - the
route that a virtual circuit follows is established at the beginning
of the call. A much more basic function of cell _switching_ occurs
during a virtual circuits operation, but this is not at the same level as
IP style routing.

I think a distinction needs to be made between 'routing' when finding
a route, and 'routing' (or switching) when retransmitting a data unit
(packet or cell) out onto the physical media chosen as the correct route.

	[..]
>Surely once I can open an ATM connection 
>from my workstation to your workstation, 
>passing across the world, through the global ATM network of switches, 
>we then become connected to the same network
>and so no internet layer is needed and IP routers or equivalent 
>will no longer be required for data transfer over the ATM network. 

In the same way that you don't need an IP router between workstations
on the same Ethernet, you are right. However the world will never be fully
ATM. Even ATM-like LANs may not be able to switch cells seamlessly with the
telcos B-ISDN offerings, necessitating some form of gatewaying. Two places 
where IP routing functions _will_ be needed are:

- At the edges of the ATM networks (i.e. between ATM and some LAN, etc)
- Between virtual subnetworks within the ATM world, which may exist for
  varieties of political, security, or financial reasons.

ATM, meaning AAL1 through AAL5 (and not including I.364, CCITTs
connectionless service), is layered underneath protocols such as IP.
It is not positioned to replace them.

gja
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Future of IP routers
Date: 25 Aug 92 16:33:13 GMT
Distribution: na
Organization: Naval Research Laboratory, DC


	Router vendors I've talked to (e.g. at the Boston IETF)
indicate that handling ATM at OC-3c rates (~155 Mbps) is not a problem
with existing technology.  A number of well known router vendors are
adding support for ATM interfaces as I write and at least one of them
told me of plans to build an integrated ATM switch/router ("srouter"
?).  These were firms that were primarily thinking in terms of IP over
AAL5.  

  Most telco firms go red in the face at hearing about AAL5 and freak
out at routing -- they seemed to be very interested in complex
bridging (e.g.  between FR and ATM) instead of admitting that IP
routing has a role to play.  As someone else noted earlier, most telco
folks erroneously believe that they understand datagram services,
while most datagram-oriented folks realise that they don't understand
circuit-oriented voice networks (telco networks) all that well.

	ATM switches _switch_ cells from an incoming VCI/VPI pair to a
different outgoing VCI/VPI pair.  Most ATM switches only _route_ at
call-setup time (which is static routing).  By contrast, IP and CLNP
use dynamic routing and so each packet is routed individually and
there is no call setup procedure.  


Ran
atkinson@itd.nrl.navy.mil
working for, but not speaking for, the Naval Research Laboratory
Newsgroups: comp.dcom.cell-relay
From: brian@dxcern.cern.ch (Brian Carpenter   CERN-CN)
Subject: Re: Future of IP routers
Organization: CERN European Lab for Particle Physics
Date: Mon, 31 Aug 1992 13:04:47 GMT

In <1992Aug30.021454.29795@u.washington.edu> gray@cac.washington.edu (Terry Gray) writes:

>One of the key reasons we use IP routers is to provide firewalls for
>an important class of faults which do not stop at bridges or repeaters.
>I believe --somebody correct me if this is incorrect-- that the same 
>issues will apply to ATM switches living in an IP environment.  For example,
>if an ARP packet (or any other broadcast packet) appears at one port 
>of an ATM switch, does it not appear on all other ports of the switch,
>assuming the appropriate AAL for handling the IP world?  

>If so, you have a terrific opportunity for one department's broadcast
>storm to become *everyone's* broadcast storm.

Right on! Weak implementations of broad/multicast protocols are the
bane of large LANs. Won't anybody listen to me: DO NOT ASK FOR OR
DESIGN FOR MULTICAST ON SWITCHED NETWORKS! (This applies to HiPPI
and Fibre Channel too. At least the IP over Fibre Channel draft
recommends an ARP server rather than ARP multicast.)

But, Terry, you don't need routers to avoid this problem - ARP and DNS
servers returning end-to-end addresses do it too. The firewall issue is
an artefact of ARP and its copycats.

Regards,
	Brian Carpenter CERN, brian@dxcern.cern.ch
			voice +41 22 767 4967, fax +41 22 767 7155
Newsgroups: comp.dcom.cell-relay
From: gja@mullian.ee.mu.oz.au (Grenville Armitage)
Subject: Re: Future of IP routers
Organization: Basket Weavers, Inc.
Date: Tue, 1 Sep 1992 00:24:44 GMT

In article <1992Aug31.091218.21819@fokus.gmd.de> icarus!mbu@fokus.gmd.de (M. Burak) writes:
	[..]
>But please tell me how will IP work over an ATM network with
>AAL type 5? What is the concept of this approach? 

I think the motives behind AAL5 were not to address the issue of
connection vs connectionless interface to higher layers. AAL5 recommends
a leaner, meaner segmentation and reassembly mechanism which is
hoped/believed/known to be better for packet orientated services than
AAL4 or 3 (which incorporate arguably unnecessary per SAR_PDU CRC
checking, etc). As mentioned elsewhere AAL5 _depends_ on cell sequence
integrity on any virtual connection it runs over.

gja
Newsgroups: comp.dcom.cell-relay