Leisner.Henr@XEROX.COM (Marty) (01/10/90)
Is there a TCP/IP printing protocol? Is there such a thing as a TCP/IP print server? Any information is appreciated, thanks, marty ARPA: leisner.henr@xerox.com GV: leisner.henr NS: leisner:wbst139:xerox UUCP: hplabs!arisia!leisner
ccruss@pollux (Russ Hobby) (01/11/90)
Currently there is no offical TCP/IP protocol for printing, and there is
a need. Amoung UNIX systems lpr is used a lot. Several printer vendors have
their own protocols.
I am in search of people interested in this problem to form an IETF Working
Group to come up with a good network printer protocol. Some of the things that
the protocol would need to consider are:
1) Authentication/security/accounting
2) Printing modes and options (Postscript, plain text, page/line size,...)
3) Scheduling priorities
4) Begin/end job control
5) Printers that are directly connected to a network or through a host.
If you are interested in working on such a protocol or just have some good
ideas, let me know.
Russ Hobby INTERNET: rdhobby@ucdavis.edu
IETF Area Director - Applications BITNET: RDHOBBY@UCDAVIS
UUCP: ...!ucbvax!ucdavis!rdhobby geof@aurora.com (Geoffrey H. Cooper) (01/11/90)
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
kjj@varese.UUCP (Kevin Johnson) (01/11/90)
In article <6434@ucdavis.ucdavis.edu> rdhobby@ucdavis.edu (Russ Hobby) writes: >Currently there is no offical TCP/IP protocol for printing, and there is >a need. Amoung UNIX systems lpr is used a lot. Several printer vendors have >their own protocols. I'm curious why there isn't an RFC addressing this... . . . >If you are interested in working on such a protocol or just have some good >ideas, let me know. apol. for tacking this in but the news posting is going out anyway... Sure, I'll byte...