[alt.fax] Domain Registration

sl@van-bc.wimsey.bc.ca (Stuart Lynne) (07/27/90)

In article <1990Jul26.025310.4158@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <961@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes:
}
}>	user@+number.phone	for dialup mail
}>	user@+number.fax	for fax
}
}What we really need is a single machine that understands both.  The originator
}should put a tone on the line so that the answering machine can automatically
}roll over to a voice phone or modem when something else calls, thus avoiding
}the need for separate lines.  It should interoperate with existing fax
}machines, converting text to fax image when it detects that it is sending
}a mail message to a fax-only device.  When 2 similar machines connect, they
}would use something resembling SMTP to exchange either text messages or
}encoded images with encapsulating headers that would allow forwarding over
}typical mail connections.  The simplest versions would probably be PC cards
}with software to view, print and manipulate using the normal PC devices.
}Standalone units might have serial ports, network connections, hard disk
}(of course), fax-style scanner and printer, etc.  A single machine could
}thus give you fax-over-internet and mail to anywhere you can dial.

Actually what I had in mind was using the existing fax protocols.
Specifically there is proposal to standardize a file transfer protocol
(BFTP) using fax modems. So if you are sending mail you fire up your T.30
protocol engine, connect to the remote end and check if they support BFTP.
If they don't you deliver the message by converting to a bitmap and sending
the image. If the remote end supports BFTP you forward a (for example) BSMTP
file containing the mail message and information on how to forward.

With some of the new modems coming out you will be able to get Fax,
1200/2400 and MNP all in one box. So the above becomes feasible. 

It will probably take another year or so before the modems are able to 
provide mechanisms to allow incoming calls to be either fax or data. Rest
assured that the modem manufacturers know that we want that. They just
havn't figured out how to do it reliably.



}>Are we going to allow them in routes?
}>
}>	site_a!site_b!+18005551234.phone!site_c!site_d!user

}Normally you would just dial up the one you want.  Do people forward faxes?

Yes, they do. And with BFTP sending a BSMTP file the above would work.

We probably do want two protocols though. 

	user@+number.phone	for dialup mail

Would allow mail to be forwarded to a remote site, assuming a 1200/2400
Hayes compatible modem at the far end. Perhaps a BSMTP file transferred
using ZModem or Kermit.

	user@+number.fax	for fax

Would allow mail to be forwarded to a remote site by sending a bit image if
the remote machine is note capable of BFTP (i.e. a real fax machine) or
using BSMTP via BFTP if the remote machine is capable.

We can make the assumption that the contents of the mail message is RFC822
compatible.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 

les@chinet.chi.il.us (Leslie Mikesell) (07/27/90)

In article <1075@van-bc.wimsey.bc.ca> sl@van-bc.wimsey.bc.ca (Stuart Lynne) writes:

>With some of the new modems coming out you will be able to get Fax,
>1200/2400 and MNP all in one box. So the above becomes feasible. 

I'm not particularly interested in 1200/2400 compatibility. 9600 baud
V.29 would work just fine for data transfers.  What I'd like to see
is a store & forward "appliance" that could send and receive between
similar machines over the phone lines with a compatibility mode for
existing fax machines.  Connections to computers would be done through
a serial or network port (or PC buss), so there would be no need for this
machine to have direct compatibility with any existing non-fax modems.
A prime requirement would be the ability to detect calls from non-compatible
equipment and roll over automatically to another built-in phone port which
could go to your choice of voice phone or modem (depending on the current
use of the existing phone line).  Thus if you want modem compatibility you
would just roll over to your choice of modems.

>It will probably take another year or so before the modems are able to 
>provide mechanisms to allow incoming calls to be either fax or data. Rest
>assured that the modem manufacturers know that we want that. They just
>havn't figured out how to do it reliably.

The way to do it reliably is to forget backwords compatibility and compromises
with interactive operation.  Go for high-speed bulk transfers to a hard
disk in the same device and your call will be finished in the time it
takes for 47 flavors of modem handshakes to even start. Hard disks are cheap
these days and many offices could justify such a device for fax-only use   
based on the time savings in scanning onto a local disk with the image
transfer (compressed if the remote is compatible) happening when the phone
lines and remote system are available.  Put the backwards compatibility on
the serial port or network link to the local computer, with perhaps a new
standard or two. 

>We probably do want two protocols though. 
>	user@+number.phone	for dialup mail
>Would allow mail to be forwarded to a remote site, assuming a 1200/2400
>Hayes compatible modem at the far end. Perhaps a BSMTP file transferred
>using ZModem or Kermit.

This would be on the serial port/normal modem side. One standard should look
very much like SMTP layered under Kermit.  The additions needed to the
protocols would be better initial handshaking for kermit to establish the
optimum modes and a BSMTP variation when the sender isn't especially
interested in the responses or is using an existing version of kermit to
transfer files.  For backwards compatibility, uucp transfers could be built
in as well.

>We can make the assumption that the contents of the mail message is RFC822
>compatible.

The other standard needed is a format for encapsulating fax images inside
of mail messages.  Optimal compression would be very important so 
uuencoding should be avoided unless the next hop is known to have
arbitrary restrictions on the message content.  This may already be
addressed by X.400 standards for multi-part messages and is, in fact
the most important part of making the scheme work since it will provide the
ability to store and retrieve images in a standard format.

"Nifty" features (perhaps optional) would be the ability to detect and
log inbound caller-id with the messages, and to use DTMF for control
functions.  For example, you might want to set up a machine to hold
your mail until you call up, punch in your access code and the fax
number where you want it printed out.

Les Mikesell
  les@chinet.chi.il.us