INTERNET-DRAFT Tom Hasting
Xerox Corporation
Bob Herriot
Sun Microsystems, Inc.
Norm Jacobs
Sun Microsystems, Inc.
Jay Martin
Underscore, Inc.
July 13, 1997
Mapping between LPD and IPP Protocols
<draft-ietf-ipp-lpd-ipp-map-00.txt>
Expires Jan 13, 1998
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This Internet-Draft specifies the mapping between (1) the commands
and operands of the "Line Printer Daemon (LPD) Protocol" specified
in RFC 1179 and (2) the operations and parameters of the Internet
Printing Protocol (IPP). One of the purposes of this document is
to compare the functionality of the two protocols. Another purpose
is to facilitate implementation of gateways between LPD and IPP.
WARNING: RFC 1179 was not on standards track. While RFC 1179 was
intended to record existing practice, in some areas it fell short.
However, this specification maps between (1) the actual current
practice of RFC 1179 and (2) IPP. This document does not attempt
to map the numerous divergent extensions to the LPD protocol that
have been made by many implementors.
Hastings, Herriot, Jacobs, Martin [Page 1]
Mapping between LPD and IPP Protocols June 27, 1997
TABLE OF CONTENTS
1. INTRODUCTION........................................................3
2. TERMINOLOGY.........................................................3
3. MAPPING BETWEEN LPD COMMANDS AND IPP OPERATIONS....................3
3.1 Print any waiting jobs ...........................................4
3.2 Receive a printer job ............................................4
3.3 Send queue state (short) .........................................5
3.4 Send queue state (long) ..........................................5
3.5 05 - Remove jobs .................................................6
4. MAPPING BETWEEN LPD SUB-COMMANDS AND IPP OPERATIONS.................6
4.1 01 - Abort job () ................................................6
4.2 02 - Receive control file ........................................7
4.3 03 - Receive data file ...........................................7
5. MAPPING OF LPD CONTROL FILE LINES TO IPP OPERATION INPUT PARAMETERS.7
6. BIBLIOGRAPHY.......................................................10
7. AUTHOR'S ADDRESSES.................................................10
Hastings, Herriot, Martin [Page 2]
Mapping between LPD and IPP Protocols June 27, 1997
Mapping between the LPD and IPP Protocols
1. Introduction
The reader of this specification is expected to be familiar with the IPP
Model and Semantics specification [1], the IPP Protocol specification
[2], and the Line Printer Daemon (LPD) protocol specification [3] as
described in RFC 1179.
RFC 1179 was written in 1990 in an attempt to document existing LPD
protocol implementations. Since then, a number of undocumented
extensions have been made by vendors to support functionality specific
to their printing solutions. All of these extensions consist of
additional control file directives. This document does not address any
of these vendor extensions. Rather it addresses existing practice
within the context of the features described by RFC 1179. Deviations of
existing practice from RFC 1179 are so indicated.
In the area of document formats, also known as page description
languages (PDL), RFC 1179 defines a fixed set with no capability for
extension. Consequently, some new PDL's are not supported, and some of
those that are supported are sufficiently unimportant now that they have
not been registered for use with the Printer MIB[4] and IPP[1] [2],
though they could be registered if desired. See the Printer MIB
specification [4] and/or the IPP Model specification [1] for
instructions for registration of document-formats with IANA. IANA lists
the registered document-formats as "printer languages".
Other LPD commands are intended to work on "text" only formats and so
are inappropriate for many contemporary document formats that completely
specify each page.
This document addresses the protocol mapping for both directions:
mapping of the LPD protocol to the IPP protocol and mapping of the IPP
protocol to the LPD protocol.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6].
The syntax of the LPD commands is given using ABNF [6].
The following tokens are used in order to make the syntax more readable:
LF stands for %x0A (linefeed)
Hastings, Herriot, Martin [Page 3]
Mapping between LPD and IPP Protocols June 27, 1997
SP stands for %x20. (space)
3. Mapping between LPD Commands and IPP Operations
This section describes the mapping between LPD on-the wire and IPP
operations. Each of the following sub-sections appear as sub-sections
of section 5 of RFC 1179.
3.1 Print any waiting jobs
Command syntax: %x01 Printer-queue-name LF
In LPD, this comment starts the daemon, if it isn't already running.
Such an equivalent operation is not provided in IPP, since the IPP
Printer is assumed to always be running, where as in LPD, the client
makes sure that the daemon is running using this command.
If an LPD-to-IPP mapper receives this LPD command, it SHALL ignore it
and send no IPP operation.
An IPP-to-LPD mapper SHALL send this LPD command after it has finished
sending all pending `Receive a printer job' commands.
3.2 Receive a printer job
Command syntax: %x02 Printer-queue-name LF
An LPD-to-IPP mapper SHALL map the 'Receive a printer job' command to
either:
. the Print-Job operation with a single data file or
. the Create-Job operation followed by a Send-Document operation
for each data file.
If a job consists of a single data file, the PrintJob operation is
RECOMMENDED.
If a job consists of more than one data file, Create Job followed by
Send-Document for each data file is REQUIRED. If the IPP Printer
doesn't support the Create-Job and Send-Document operations, the LPD-to-
IPP mapper SHALL submit each data file as a separate Print-Job operation
(thereby converting a single LPD job into multiple IPP jobs).
ISSUE: Ok that I changed so that the mapper shall break a multi-document
job into separate jobs, one IPP job for each LPD data file, instead of
error return?
Hastings, Herriot, Martin [Page 4]
Mapping between LPD and IPP Protocols June 27, 1997
NOTE: if Create-Job is used, it MUST precede the Send-Document operation
even if the LPD control file, which supplies attributes for Create-Job,
arrives after all documents.
An IPP-to-LPD mapper SHALL map the following IPP operations to this LPD
command:
. Print-Job
. Print-uri
. Create-Job followed by Send-Document or Send-URI for each
document
The mechanism for mapping between an LPD Printer-queue-name operand and
the IPP "printer-uri" parameter is not defined in this document.
ISSUE: error code conversion.
See the next section for the mapping of the LPD "second level commands"
to IPP input-parameters.
3.3 Send queue state (short)
Command syntax: %x03 Printer-queue-name *( SP ( User-Name / job-number)
)
If the LPD command contains only the Printer-queue-name operand, the
LPD-to-IPP mapper SHALL use the Get-Attributes operation of the
corresponding IPP Printer to get printer-state information and the Get-
Jobs operation of the Printer to get information about all of the jobs.
With Get-Attributes, it SHALL request the "printer-state" and "printer-
state-reasons" attributes. With Get-Jobs, it SHALL request the "number-
of-intervening-jobs", "job-originating-user", "job-name", "document-
name" (or "document-uri"), and "job-k-octets".
NOTE: RFC 1179 does not specify what attributes are returned in
response to a 'Send queue state' (short) command, but leaves it up to
implementation. The IPP attributes specified in this specification
reflect existing practice.
NOTE: This specification does not specify how the LPD-to-IPP mapper
maps: (1) the LPD Printer-queue-name operand to the IPP "printer-uri"
parameter or (2) the LPD job-number operand to the IPP "job-uri"
parameter, since the format of these URIs is opaque in the IPP protocol
and is implementation-dependent.
Hastings, Herriot, Martin [Page 5]
Mapping between LPD and IPP Protocols June 27, 1997
If the LPD command contains one or more User-name operands, the LPD-to-
IPP mapper SHALL get all the jobs as above using the Get-Jobs operation
on the Printer and then do its own filtering on the returned value of
the "job-originating-user" attribute for each job.
If the LPD command contains only job-number operands, the LPD-to-IPP
mapper SHALL either (1) get all the jobs as above using the Get-Jobs
operation on the Printer and then do its own filtering or (2) get each
specified job individually using separate Get-Attributes operations
(multiple jobs may be requested in a single IPP connection with multiple
Get-Attribute operations, one for each job).
The IPP-to-LPD mapper shall use the long version of this command. See
that command.
3.4 Send queue state (long)
Command syntax: %x04 printer-name *( SP ( user-name / job-number) )
Same mapping as the 'Send queue state' (short) command. The IPP client
supplies a longer list of requested attributes to the Get-Jobs or Get-
Attributes operations.
The LPD-to-IPP mapper should specify additional attributes than the ones
listed for the 'Send queue state' (short) command.
NOTE: RFC 1179 does not specify what attributes are returned in
response to a 'Send queue state' (short) command, but leaves it up to
implementation.
The IPP-to-LPD mapper shall use this command to get what attributes it
can from the LPD server.
3.5 05 - Remove jobs
Command syntax: %x05 Printer-queue-name SP agent *(SP (User-name / job-
number))
The agent operand is the user-name of the user initiating the 'Remove
jobs' command. The special user-name 'root' indicates a privileged
user.
The LPD-to-IPP mapper shall map this command to the Cancel-Job
operation.
This command with the Printer-queue-name operand and one job-number
operand is the same as the IPP Cancel-Job operation when the client
supplies just the job URI. Multiple jobs may be canceled in IPP in a
Hastings, Herriot, Martin [Page 6]
Mapping between LPD and IPP Protocols June 27, 1997
single connection with multiple Cancel-Job operations. In IPP only a
privileged operator may cancel jobs belonging to another user.
NOTE: This specification does not specify how the LPD-to-IPP mapper
maps: (1) the LPD Printer-queue-name to the IPP "printer-uri" or (2) the
LPD job-number to the IPP "job-uri", since the format of these URIs is
opaque in the IPP protocol and is implementation-dependent.
There is no IPP equivalent for the LPD 'Remove jobs' command with just
the Printer-queue-name operand supplied, since IPP provides no way to
cancel the current job.
There is no IPP equivalent for the LPD 'Remove jobs' command with a
User-name operand supplied, since IPP provides no way to cancel a job
specified by user name.
The LPD-to-IPP mapper shall map a Cancel-Job operation to this command.
There are some major issues about setting the agent.
4. Mapping between LPD Sub-Commands and IPP Operations
This section describes the mapping between LPD sub-commands and IPP
operations. Each of the following sub-sections appear as sub-sections
of section 6 of RFC 1179. The operands of the sub-commands appear in
parens in the sub-headings
4.1 01 - Abort job ()
Sub-command syntax: %x01
This sub-command is intended to abort any job transfer in process. If
an IPP Create-Job operation and/or a Send-Document operation were
performed on behalf of the receive job command that is being aborted, an
IPP Cancel-Job operation should be issued for the job URI that was
returned by the Printer on which the Create-Job operation was performed.
Also, any temporary files created while processing the 'Receive job
request' should be cleaned up, and the connection to the client should
be closed. Finally, this sub-command is implied if at any time the
connection between the LPD client and server is terminated before an
entire print job has been transferred via an LPD 'Receive job request'.
ISSUE: is IPP defined at this point to abort a job whose connection is
closed before the job has been fully received. If so, that is an
alternate and simpler way to abort the job.
Hastings, Herriot, Martin [Page 7]
Mapping between LPD and IPP Protocols June 27, 1997
4.2 02 - Receive control file
Sub-command syntax: %x02 Number-of-bytes-in-control-file, Name-of-
control-file
This sub-command is roughly equivalent to the IPP Create-Job operation.
Once the control file has been has been received, it's contents should
be translated, and an appropriate IPP Create-Job operation performed.
However, some information, such as Document-Name go in the Send-Document
operation.
4.3 03 - Receive data file
Sub-command syntax: %x03 Number-of-bytes-in-data-file Name-of-data-file
This sub-command is roughly equivalent to the IPP Send-Document
operation. If the control file has been previously received, and it's
corresponding IPP Create-Job operation performed, an IPP Send-Document
operation can be performed using the job URI returned by the IPP Create-
Job operation.
When performing the Send-Document operation, the size of the document
data MUST be specified. Unfortunately RFC-1179 alludes to a method for
passing an arbitrary length data file. This is described as being done
by using an octet-count of zero, however the description isn't complete,
and in practice, no implementations allow sending or receiving arbitrary
length data files.
5. Mapping of LPD control file lines to IPP Operation Input Parameters
This section describes the mapping from LPD control file lines to IPP
operation input parameters for the Print-Job, Create-Job, and Send-
Document operations. Each of the following sub-sections appear as sub-
sections of section 7 of RFC 1179.
ISSUE: somewhere, we need to map the LPD query format to IPP attributes.
In LPD text operands have a maximum length of 31 or 99 while IPP input
parameters have a maximum of 255 characters. Therefore, no data is lost
when mapping from LPD to IPP. However, when mapping from IPP to LPD,
there may be some data loss if the IPP parameters exceed the maximum
length of the LPD equivalent operands.
In the following table, IPP input parameter names are indicated in
double quotes (") and input parameter values are indicated in single
quotes ('). Values of the IPP "document-format" attribute that could be
registered, but are not currently, are indicated with "**".
Hastings, Herriot, Martin [Page 8]
Mapping between LPD and IPP Protocols June 27, 1997
Where there is a one-to-one mapping, both directions are specified.
Where IPP has none, the LPD-to-IPP the attribute is ignored, and in the
IPP-to-LPD the LPD feature is left unspecified.
LPD command Equivalent IPP input parameter(s)
C Class for banner None.
page
H Originating Host "job-originating-host"
I Indent Printing None.
J Job name for banner "job-name"
page
L Print banner page "job-sheets" = any but 'none'
Absence of an `L' directive
indicates that ``job-sheets=none''
is set.
M Mail When Printed "notification-events" = 'job-
completion' and "notification-
method" = 'mailto://Job-
originating-user@job-originating-
host'
N Name of source file "document-name" This is on a per
data file basis
P User identification "job-originating-user"
S Symbolic link data None.
T Title for pr None.
U Unlink data file None.
W Width of output None.
1 troff R font None.
2 troff I font None.
3 troff B font None.
4 troff S font None.
Hastings, Herriot, Martin [Page 9]
Mapping between LPD and IPP Protocols June 27, 1997
c Plot CIF file "document-format" = 'CIF' **
d Print DVI file "document-format" = 'TeX DVI' **
f Print formatted file "document-format" = 'Automatic'
In practice, this value is often
overloaded. It is often used with
any format of document data
including PostScript and PCL data.
g Plot file "document-format" =
'BSDPlotLibrary' **
k reserved for None.
Kerberized clients
and servers This is unimplemented in LPD
implementations. It was a place
holder for future work that never
occurred.
l Print file leaving "document-format" = 'Automatic'
control characters
In practice, this is often used as
a rough equivalent to the `f'
directive. Again it may mean one
of many document formats.
n Print ditroff output "document-format" = 'ditroff' **
file
o Print Postscript "document-format" = 'ps'
output file "document-format" = 'PS'(7)
o is recognized by LPD-to-IPP, but
never generated in IPP-to-LPD.
Rather `f' is used.
This was not implemented in any
RFC-1179 implementations until
very recently in WinNT.
p Print file with 'pr' None.
format
It therefore is equivalent to `f'
or `l'
Hastings, Herriot, Martin [Page 10]
Mapping between LPD and IPP Protocols June 27, 1997
r File to print with "document-format" = 'FORTRAN' **
FORTRAN carriage
control
t Print troff output "document-format" = 'troff' **
file
v Print raster file "document-format" = 'RasterFormat'
**
z reserved for future None.
use with the
Palladium print This was reserved for the MIT
system Palladium print system, but was
never used by that system.
6. Bibliography
[1] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet
Printing Protocol/1.0: Model and Semantics", <draft-ietf-ipp-model-
02.txt>, July 1997.
[2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing
Protocol/1.0: Protocol specification", <draft-ietf-ipp-protocol-00.txt>,
July 1997.
[3] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, August
1990.
[4] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J.,
"Printer MIB", RFC 1759, March 1995.
[5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 , March 1997
[6] D. Crocker et al., ``ugmented BNF for Syntax Specifications:
ABNF', draft-ietf-drums-abnf-02.txt.
7. Author's Addresses
Thomas N. Hastings
Xerox Corporation
701 S. Aviation Blvd., ESAE-231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
Hastings, Herriot, Martin [Page 11]
Mapping between LPD and IPP Protocols June 27, 1997
Robert Herriot
Sun Microsystems Inc.
2550 Garcia Ave., MPK-17
Mountain View, CA 94043
Phone: 415-786-8995
Fax: 415-786-7077
Email: robert.herriot@eng.sun.com
Norm Jacobs
Sun Microsystems Inc.
1430 Owl Ridge Rd.
Colorado Springs, CO 80919
Phone: (719) 532-9927
Fax: (719) 535-0956
Email: Norm.Jacobs@Central.sun.com
Jay Martin
Underscore Inc.
41-C Sagamore Park Rd.
Hudson, NH 03051-4915
Phone: (603) 889-7000
Fax: (603) 889-2600
Email: jkm@underscore.com
Hastings, Herriot, Martin [Page 12]
