After a connection has been established, a request can be
sent to the lpd server. The
request consists of a single octet indicating the request
type, followed by the printer (or print queue) name, followed
by a set of options for the request, followed by a LF (line
feed) character.
Table 19-1. RFC1179 Commands
NNN
RFC1179
Operation
program
1
yes
start print
lpc
2
yes
transfer a printer
job
lpr
3
yes
print short form of
queue status
lpr
4
yes
print long form of
queue status
lpr
5
yes
remove jobs
lprm
6
LPRng
do control
operation
lpc
7
LPRng
transfer a block format
print job
lpr
8
LPRng
secure command
transfer
lpc
9
LPRng
verbose status
information
lpr
After the request has been sent, then a reply will be
returned. In general the reply has the following form:
\000\n Success
\NNN\n Failure (NNN is error code)
text\n Text or status information
As can be seen, this protocol is extremely simple, but
there are a set of problems due to the loosely written
language of RFC1179.
Firstly, while RFC1179 sets limits on the lengths of
commands, it does not strictly set limits on the
characters set used in the commands. This can result in
problems when trying to print status information, headers
on banners, and other details.
The original RFC1179 protocol did not provide any way
to do remote control of queues or lpd servers. This has been added to the
protocol. As a side effect, if you try to use lpc to control a non-LPRng printer, it will not work.
You can specify that a network printer is non-LPRng by using the remote_support=RQVMC option and specify
the operations supported by the printer. The letters R,
Q, M, and C stand for lpr, lpq, lprm, and lpc operations respectively, and
indicate that these are supported. If remote_support does not allow a particular
operation, then the LPRng
software will not send a corresponding request to the
printer. For example, remote_support=R would restrict operations
to spooling jobs only, and the LPRng software would not query the
printer for status.