Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!aurora!geof
From: geof@aurora.com (Geoffrey H. Cooper)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP/IP printing protocol
Summary: Yes, 2 "standards"....IMAGEN, DEC
Message-ID: <1990Jan10.184557.25715@aurora.com>
Date: 10 Jan 90 18:45:57 GMT
References: <900109-093140-4953@Xerox>
Reply-To: geof@aurora.UUCP (Geoffrey H. Cooper)
Organization: The Aurora Group, Palo Alto, CA
Lines: 65

In article <900109-093140-4953@Xerox> Leisner.Henr@XEROX.COM (Marty) writes:
>Is there a TCP/IP printing protocol?  Is there such a thing as a TCP/IP print server?

IMAGEN (now QMS) has been selling TCP-IP print servers since 1983 for
their line of high-end printers (20ppm, duplex, many
emulations/languages).  QMS itself has a product called "PrintLink"
that also speaks TCP-IP (I think it only uses a standard FTP server).
DEC also has a TCP-IP print server that runs at 40ppm.

DEC has its own protocol, which is somewhat more complex than
IMAGEN's.  I'll let one of the DEC people explain it, since I'm not
fully familiar with it.

IMAGEN's protocol was designed to maximize simplicity, since the
printer has other mechanisms for communicating everything about a
print job (#copies, duplex on/off, emulation to select, etc).  The
protocols are documented in manuals shipped with the printers.  There
are three protocols: "transport1", "status1", "accounting1".  (The "1"
part was an optimistic hope that there would be fancier protocols to
come.  That these were never really needed is partially a tribute to
how much can be achieved with how little and partially a sign that
people are only mildly interested in doing fancy things with their
printers). 

IMAGEN's approach has been to distribute software for popular machines
that implements its printing protocols.

Status1 is a UDP-based protocol.  The printer listens on a dedicated
UDP port (35) for packets, and returns every packet it receives with a
description of the current state of the printer: print a job, paper
jam, out of paper, etc..

Transport1 is a TCP-based protocol.  The printer listens on a
dedicated TCP port (35) for connections.  All data sent down the
connection is processed as a single print job.  The sender sends a
FIN to indicate end-of-job, and the printer responds with its FIN when
it is willing to accept full responsibility for printing the tail of
the job.

To talk to the printer, Status1 and Transport1 are enjoined into a
"combined protocol" that arbitrates multiple access.  Under this
protocol, the sender probes with Status1 until it sees that the
printer is ready to accept a new job (most implementations of the
suite do not locally spool data, and for other reasons they can't 
accept a TCP connection until they are actually ready to start
processing the print job).  Then it attempts to open a Transport1
connection.  If this fails, the loop repeats.

In the early days, host UDP support of sometimes poor (hello apollo)
so a modified combined protocol also exists whereby only Transport1 is
used.  In the rare case that I personally did an installation, I was
able to implement this with a shell script that piped into telnet, so
that I could demo the printer immediately.

Accounting1 is a UDP-based protocol.  The printer can be configured
with a number of trusted "accounting hosts" and sends datagram packets
to them at the end of each job.  The protocol is not completely
reliable, but you can make it pretty useful if you have multiple hosts
receiving UDP packets (there was a paper done some time ago about the
doing reliable broadcasts without ACK's).  This is probably the
weakest link of the "suite".

- Geof
-- 
geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com