draft-ietf-ipp-lpd-ipp-map-00.txt   draft-ietf-ipp-lpd-ipp-map-01.txt 
INTERNET-DRAFT Tom Hasting
Xerox Corporation INTERNET-DRAFT
Bob Herriot
Robert Herriot (editor)
Sun Microsystems, Inc. Sun Microsystems, Inc.
Tom Hastings
Xerox Corporation
Norm Jacobs Norm Jacobs
Sun Microsystems, Inc. Sun Microsystems, Inc.
Jay Martin Jay Martin
Underscore, Inc. Underscore, Inc.
July 13, 1997 July 30, 1997
Mapping between LPD and IPP Protocols Mapping between LPD and IPP Protocols
<draft-ietf-ipp-lpd-ipp-map-01.txt>
<draft-ietf-ipp-lpd-ipp-map-00.txt> Expires Jan 30, 1998
Expires Jan 13, 1998
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas, and
and its working groups. Note that other groups may also distribute its working groups. Note that other groups may also distribute working
working documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
skipping to change at page 1, line 47 skipping to change at page 1, line 48
Abstract Abstract
This Internet-Draft specifies the mapping between (1) the commands This Internet-Draft specifies the mapping between (1) the commands
and operands of the "Line Printer Daemon (LPD) Protocol" specified and operands of the "Line Printer Daemon (LPD) Protocol" specified
in RFC 1179 and (2) the operations and parameters of the Internet in RFC 1179 and (2) the operations and parameters of the Internet
Printing Protocol (IPP). One of the purposes of this document is Printing Protocol (IPP). One of the purposes of this document is
to compare the functionality of the two protocols. Another purpose to compare the functionality of the two protocols. Another purpose
is to facilitate implementation of gateways between LPD and IPP. is to facilitate implementation of gateways between LPD and IPP.
WARNING: RFC 1179 was not on standards track. While RFC 1179 was WARNING: RFC 1179 was not on standards track. While RFC 1179 was
intended to record existing practice, in some areas it fell short. intended to record existing practice, it fell short in some areas.
However, this specification maps between (1) the actual current However, this specification maps between (1) the actual current
practice of RFC 1179 and (2) IPP. This document does not attempt practice of RFC 1179 and (2) IPP. This document does not attempt
to map the numerous divergent extensions to the LPD protocol that to map the numerous divergent extensions to the LPD protocol that
have been made by many implementors. have been made by many implementers.
Mapping between LPD and IPP Protocols June 27, 1997
Jacobs, Martin Expires January 30, 1998
TABLE OF CONTENTS TABLE OF CONTENTS
1. INTRODUCTION........................................................3 1. Introduction........................................................3
2. Terminology.........................................................3
2. TERMINOLOGY.........................................................3 3. Mapping from LPD Commands to IPP Operations.........................4
3. MAPPING BETWEEN LPD COMMANDS AND IPP OPERATIONS....................3
3.1 Print any waiting jobs ...........................................4 3.1 Print any waiting jobs ...........................................4
3.2 Receive a printer job ............................................4 3.2 Receive a printer job ............................................4
3.2.1 Abort job ....................................................5
3.2.2 Receive control file .........................................6
3.2.3 Receive data file ............................................6
3.3 Send queue state (short) .........................................6
3.4 Send queue state (long) ..........................................8
3.5 Remove jobs ......................................................9
4. Mapping of LPD Control File Lines to IPP Parameters................10
4.1 Required Job Functions ..........................................10
4.2 Optional Job Functions ..........................................11
4.3 Required Document Functions .....................................12
4.4 Recommended Document Functions ..................................13
5. Mapping from IPP operations to LPD commands........................13
5.1 Get-Operations ..................................................13
5.2 Print-Job .......................................................13
5.3 Print-URI .......................................................14
5.4 Validate-Job ....................................................15
5.5 Create-Job ......................................................15
5.6 Send-Document ...................................................15
5.7 Send-URI ........................................................15
5.8 Cancel-Job ......................................................15
5.9 Get-Attributes ..................................................16
5.10 Get-Jobs .......................................................17
6. Mapping of IPP Parameters to LPD Control File Lines................17
6.1 Required Job Functions ..........................................17
6.2 Optional Job Functions ..........................................18
6.3 Required Document Functions .....................................18
7. References.........................................................19
8. Author's Addresses.................................................19
9. Appendix A: ABNF Syntax for response of Send-queue-state (short)...20
10. Appendix B: ABNF Syntax for response of Send-queue-state (long)...20
11. Appendix C: Unsupported LPD functions.............................21
3.3 Send queue state (short) .........................................5 Jacobs, Martin Expires January 30, 1998
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
Mapping between LPD and IPP Protocols June 27, 1997
Mapping between the LPD and IPP Protocols Mapping between the LPD and IPP Protocols
1. Introduction 1. Introduction
The reader of this specification is expected to be familiar with the IPP The reader of this specification is expected to be familiar with the IPP
Model and Semantics specification [1], the IPP Protocol specification Model and Semantics specification [1], the IPP Protocol specification
[2], and the Line Printer Daemon (LPD) protocol specification [3] as [2], and the Line Printer Daemon (LPD) protocol specification [3] as
described in RFC 1179. described in RFC 1179.
RFC 1179 was written in 1990 in an attempt to document existing LPD RFC 1179 was written in 1990 in an attempt to document existing LPD
protocol implementations. Since then, a number of undocumented protocol implementations. Since then, a number of undocumented
extensions have been made by vendors to support functionality specific extensions have been made by vendors to support functionality specific
to their printing solutions. All of these extensions consist of to their printing solutions. All of these extensions consist of
additional control file directives. This document does not address any additional control file commands. This document does not address any of
of these vendor extensions. Rather it addresses existing practice these vendor extensions. Rather it addresses existing practice within
within the context of the features described by RFC 1179. Deviations of the context of the features described by RFC 1179. Deviations of
existing practice from RFC 1179 are so indicated. existing practice from RFC 1179 are so indicated.
Other LPD control file commands in RFC 1179 are obsolete. They are
intended to work on "text" only formats and are inappropriate for many
contemporary document formats that completely specify each page. This
document does not address the support of these obsolete features.
In the area of document formats, also known as page description In the area of document formats, also known as page description
languages (PDL), RFC 1179 defines a fixed set with no capability for languages (PDL), RFC 1179 defines a fixed set with no capability for
extension. Consequently, some new PDL's are not supported, and some of extension. Consequently, some new PDL's are not supported, and some of
those that are supported are sufficiently unimportant now that they have 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], 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 though they could be registered if desired. See the Printer MIB
specification [4] and/or the IPP Model specification [1] for specification [4] and/or the IPP Model specification [1] for
instructions for registration of document-formats with IANA. IANA lists instructions for registration of document-formats with IANA. IANA lists
the registered document-formats as "printer languages". 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: This document addresses the protocol mapping for both directions:
mapping of the LPD protocol to the IPP protocol and mapping of the IPP mapping of the LPD protocol to the IPP protocol and mapping of the IPP
protocol to the LPD protocol. protocol to the LPD protocol. The former is called the "LPD-to-IPP
mapper" and the latter is called the "IPP-to-LPD mapper".
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [6]. document are to be interpreted as described in RFC 2119 [6].
RFC 1179 uses the word "command" in two contexts: for over-the-wire
operations and for command file functions. This document SHALL use the
word "command" for the former and the phrase "functions" for the latter.
The syntax of the LPD commands is given using ABNF [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: The following tokens are used in order to make the syntax more readable:
LF stands for %x0A (linefeed)
Mapping between LPD and IPP Protocols June 27, 1997
LF stands for %x0A (linefeed)
Jacobs, Martin Expires January 30, 1998
SP stands for %x20. (space) SP stands for %x20. (space)
DIGIT stands for %x30-39 ("0" to "9")
3. Mapping between LPD Commands and IPP Operations 3. Mapping from LPD Commands to IPP Operations
This section describes the mapping between LPD on-the wire and IPP This section describes the mapping from LPD commands to IPP operations.
operations. Each of the following sub-sections appear as sub-sections Each of the following sub-sections appear as sub-sections of section 5
of section 5 of RFC 1179. of RFC 1179.
The following table summarizes the IPP operation that the mapper uses
when it receives an LPD command. Each section below gives more detail.
LPD command IPP operation
print-any-waiting-jobs ignore
receive-a-printer-job Print-Job or Create-Job/Send-Document
send queue state Get-Attributes (printer) and Get-Jobs
(short or long)
remove-jobs Cancel-Job
3.1 Print any waiting jobs 3.1 Print any waiting jobs
Command syntax: %x01 Printer-queue-name LF Command syntax:
In LPD, this comment starts the daemon, if it isn't already running. print-waiting-jobs = %x01 printer-name LF
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 This command causes the LPD daemon check its queue and print any waiting
and send no IPP operation. jobs. An IPP printer handles waiting jobs without such a nudge.
An IPP-to-LPD mapper SHALL send this LPD command after it has finished If the mapper receives this LPD command, it SHALL ignore it and send no
sending all pending `Receive a printer job' commands. IPP operation.
3.2 Receive a printer job 3.2 Receive a printer job
Command syntax: %x02 Printer-queue-name LF Command syntax:
An LPD-to-IPP mapper SHALL map the 'Receive a printer job' command to receive-job = %x02 printer-name LF
either:
. the Print-Job operation with a single data file or The control file and data files mentioned in the following paragraphs
are received via LPD sub-commands that follow this command. Their
mapping to IPP commands and attributes is described later in this
section.
. the Create-Job operation followed by a Send-Document operation The mapper maps the 'Receive a printer job' command to either:
for each data file.
If a job consists of a single data file, the PrintJob operation is . the Print-Job operation which includes a single data file or
RECOMMENDED. . the Create-Job operation followed by one Send-Document
operation for each data file.
If a job consists of more than one data file, Create Job followed by If the IPP printer supports both Create-Job and Send-Document, and if a
Send-Document for each data file is REQUIRED. If the IPP Printer job consists of:
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 Jacobs, Martin Expires January 30, 1998
job into separate jobs, one IPP job for each LPD data file, instead of . a single data file, the mapper SHOULD use the PrintJob
error return? operation, but MAY use the Create-Job and Send-Document
Mapping between LPD and IPP Protocols June 27, 1997 operations.
. more than one data file, the mapper SHALL use Create Job
followed by one Send-Document for each received LPD data file.
NOTE: if Create-Job is used, it MUST precede the Send-Document operation If the IPP printer does not support both Create-Job and Send-Document,
even if the LPD control file, which supplies attributes for Create-Job, and if a job consists of:
arrives after all documents.
An IPP-to-LPD mapper SHALL map the following IPP operations to this LPD . a single data file, the mapper SHALL use the PrintJob
command: operation.
. more than one data file, the mapper SHALL submit each received
LPD data file as a separate Print-Job operation (thereby
converting a single LPD job into multiple IPP jobs).
. Print-Job If the mapper uses Create-Job and Send-Document, it MUST send the
Create-Job operation before it sends any Send-Document operations
whether the LPD control file, which supplies attributes for Create-Job,
arrives before or after all LPD data files.
. Print-uri NOTE: This specification does not specify how the mapper maps: the LPD
Printer-name operand to the IPP "printer-uri" parameter.
. Create-Job followed by Send-Document or Send-URI for each The following 3 sub-sections gives further details about the mapping
document from LPD receive-a-printer-job sub-commands. Each of the following
sub-sections appear as sub-sections of section 6 of RFC 1179.
The mechanism for mapping between an LPD Printer-queue-name operand and ISSUE: the mapper needs to maintain information such as the mapping of
the IPP "printer-uri" parameter is not defined in this document. each job-number to its corresponding job-URI. It would be nice for IPP
to support an "scratch-pad" attribute for the mapper to encode such
information. Then it wouldn't have to maintain this information
separately.
ISSUE: error code conversion. 3.2.1 Abort job
See the next section for the mapping of the LPD "second level commands" Sub-command syntax:
to IPP input-parameters.
abort-job = %x1 LF
This sub-command of receive-a-printer-job is intended to abort any job
transfer in process.
If the mapper receives this sub-command, it SHALL cancel the job that it
is in the process of transmitting.
If the mapper is in the process of sending a Print-Job or Create-Job
operation, it terminates the job either by closing the connection, or
performing the Cancel-Job operation with the job-uri that it received
from the Print-Job or Create-Job operation.
NOTE: 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-a-printer-job request.
Jacobs, Martin Expires January 30, 1998
3.2.2 Receive control file
Sub-command syntax:
receive-control-file = %x2 number-of-bytes SP name-of-control-file LF
number-of-bytes = 1*DIGIT
name-of-control-file = "cfA" job-number client-host-name
; e.g. "cfA123woden"
job-number = 3DIGIT
client-host-name = <a host name>
This sub-command is roughly equivalent to the IPP Create-Job operation.
The mapper SHALL use the contents of the received LPD control file to
create IPP parameter and attribute values to transmit with the Print-Job
or Create-Job operation.
3.2.3 Receive data file
Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file
receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
number-of-bytes = 1*DIGIT
name-of-data-file = "df" letter job-number client-host-name
; e.g. "dfA123woden for the first file
letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z"
; first file is "A",
; second "B", and 52nd file is "z"
job-number = 3DIGIT
client-host-name = <a host name>
This sub-command is roughly equivalent to the IPP Send-Document
operation.
The mapper SHALL use the contents of the received LPD data file as the
data to transmit with the IPP Print-Job or Send-Document operation.
Although RFC-1179 alludes to a method for passing an unspecified
length data file by using an octet-count of zero, no implementations
support this feature.. The mapper SHALL reject a job that has a value of
0 in the number-of-bytes field.
3.3 Send queue state (short) 3.3 Send queue state (short)
Command syntax: %x03 Printer-queue-name *( SP ( User-Name / job-number) Command syntax:
)
If the LPD command contains only the Printer-queue-name operand, the send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF
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 The mapper's response to this command includes information about the
response to a 'Send queue state' (short) command, but leaves it up to printer and its jobs. RFC 1179 specifies neither the information nor the
implementation. The IPP attributes specified in this specification format of its response. This document requires the mapper to follow
reflect existing practice. existing practice as specified in this document.
Jacobs, Martin Expires January 30, 1998
NOTE: This specification does not specify how the LPD-to-IPP mapper The mapper SHALL produce a response in the following format which
maps: (1) the LPD Printer-queue-name operand to the IPP "printer-uri" consists of a printer-status line optionally followed by a heading line,
parameter or (2) the LPD job-number operand to the IPP "job-uri" and a list of jobs. This format is defined by examples below. Appendix A
parameter, since the format of these URIs is opaque in the IPP protocol contains the ABNF syntax.
and is implementation-dependent.
Mapping between LPD and IPP Protocols June 27, 1997 For an printer with no jobs, the response starts in column 1 and is:
If the LPD command contains one or more User-name operands, the LPD-to- no entries
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 For a printer with jobs, an example of the response is:
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 killtree is ready and printing
that command. Rank Owner Job Files Total Size
active fred 123 stuff 1204 bytes
1st smith 124 resume, foo 34576 bytes
2nd fred 125 more 99 bytes
3rd mary 126 mydoc 378 bytes
4th jones 127 statistics.ps 4567 bytes
5th fred 128 data.txt 9 bytes
The column numbers of above headings and job entries are:
| | | | |
01 08 19 35 63
The mapper SHALL produce each field above from the following IPP
attribute:
LPD field IPP attribute special conversion details
printer- printer-state and For a printer-state of idle or
status printer-state-reasons processing, the mapper SHALL use
the formats above. For stopped,
the mapper SHALL use printer-
state-reasons to produce an
unspecified format for the error.
rank number-of- the mapper SHALL the format above
intervening-jobs
owner job-originating-user unspecified conversion; job-
originating-user may be the
mapper's user-name
job job-uri unspecified conversion
files document-name the mapper shall create a comma
separated list of the document-
names and then truncate this list
to the first 24 characters
total- job-k-octets the mapper shall multiple the
size value of job-k-octets by 1024.
A mapper SHOULD use the job attribute number-of-intervening-jobs rather
than the job's position in a list of jobs to determine `rank' because a
Printer may omit jobs that it wants to keep secret. If a printer doesn't
Jacobs, Martin Expires January 30, 1998
support the job attribute number-of-intervening-jobs, a mapper MAY use
the job's position.
ISSUE: is job-k-octets the sum of the bytes of each document times the
number of copies? If so, "total-size" is 1024 times job-k-octets. The
model document needs clarification.
In order to obtain the information specified above, The LPD-to-IPP
mapper SHALL use the Get-Attributes operation of the printer to get
printer-status and SHOULD use the Get-Jobs operation to get information
about all of the jobs. If the LPD command contains job-numbers or user-
names, the mapper handles the filtering of the response because Get-Jobs
has no way to limit jobs to those of a particular user. If the LPD
command contains job-numbers but no user-names, the mapper MAY use Get-
Attributes on each converted job-number rather than Get-Jobs.
NOTE: This specification does not define how the mapper maps the LPD
Printer-name operand to the IPP "printer-uri" parameter.
3.4 Send queue state (long) 3.4 Send queue state (long)
Command syntax: %x04 printer-name *( SP ( user-name / job-number) ) Command syntax:
Same mapping as the 'Send queue state' (short) command. The IPP client send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
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 The mapper's response to this command includes information about the
listed for the 'Send queue state' (short) command. printer and its jobs. RFC 1179 specifies neither the information nor the
format of its response. This document requires the mapper to follow
existing practice as specified in this document.
NOTE: RFC 1179 does not specify what attributes are returned in The mapper SHALL produce a response in the following format which
response to a 'Send queue state' (short) command, but leaves it up to consists of a printer-status line optionally followed a list of jobs,
implementation. where each job consists of a blank line, a description line, and one
line for each file. The description line contains the user-name, rank,
job-number and host. This format is defined by examples below. Appendix
B contain the ABNF syntax.
The IPP-to-LPD mapper shall use this command to get what attributes it For an printer with no jobs the response is:
can from the LPD server.
3.5 05 - Remove jobs no entries
Command syntax: %x05 Printer-queue-name SP agent *(SP (User-name / job- For a printer with jobs, an example of the response is:
number))
The agent operand is the user-name of the user initiating the 'Remove killtree is ready and printing
jobs' command. The special user-name 'root' indicates a privileged
user.
The LPD-to-IPP mapper shall map this command to the Cancel-Job fred: active [job 123 tiger]
2 copies of stuff 602 bytes
smith: 1st [job 124 snail]
2 copies of resume 7088 bytes
2 copies of foo 10200 bytes
fred: 2nd [job 125 tiger]
Jacobs, Martin Expires January 30, 1998
more 99 bytes
The column numbers of above headings and job entries are:
| | |
01 09 41
Although the format of the long form is different from the format of the
short form, their fields are identical except for the copies and host
fields which are only in the long form. For fields other than the host
and copies fields, see the preceding section. For the host field see the
table below.
LPD field IPP attribute special conversion details
host job-originating-host unspecified conversion; job-
originating-host may be the
mapper's host
copies copies the mapper shall assume the
value of copies precedes the
string "copies of "; otherwise,
the value of copies is 1.
NOTE: This specification does not define how the mapper maps the LPD
Printer-name operand to the IPP printer-uri parameter.
3.5 Remove jobs
Command syntax:
remove-jobs = %x05 printer-name SP agent
*(SP(user-name / job-number)) LF
The agent operand is the user-name of the user initiating the remove-
jobs command. The special user-name 'root' indicates a privileged user
who can remove jobs whose user-name differs from the agent..
The mapper SHALL issue one Cancel-Job operation for each job referenced
by the remove-jobs command. Each job-number in the remove-jobs command
references a single job. Each user-name in the remove-jobs command
implicitly references all jobs owned by the specified user. The active
job is implicitly referenced when the remove-jobs command contains
neither job-numbers nor user-names. The mapper MAY use Get-Job to
determine the job-uri of implicitly referenced jobs.
The mapper SHALL not use the agent name of `root' when end-users cancel
their own jobs. Violation of this rule creates a potential security
violation, and it may cause the printer to issue a notification that
misleads a user into thinking that some other person canceled the job.
If the agent of a remove-jobs command for a job J is the same as the
user name specified with the `P' function in the control file for job J,
Jacobs, Martin Expires January 30, 1998
then the mapper SHALL ensure that the caller of the Cancel-Job command
for job J is the same as job-originating-user for job J.
Note: This requirement means that a mapper must be consistent in who the
receiver perceives as the caller of IPP operations. The mapper either
acts as itself or acts on behalf of another user. The latter is
preferable if it is possible. This consistency is necessary between
Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but
it is also desirable for other operations. For example, Get-Jobs may
give more information about job submitted by the caller of this
operation. operation.
This command with the Printer-queue-name operand and one job-number NOTE: This specification does not define how the mapper maps: (1) the
operand is the same as the IPP Cancel-Job operation when the client LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to
supplies just the job URI. Multiple jobs may be canceled in IPP in a the IPP "job-uri".
Mapping between LPD and IPP Protocols June 27, 1997
single connection with multiple Cancel-Job operations. In IPP only a NOTE: This specification does not specify how the mapper maps the LPD
privileged operator may cancel jobs belonging to another user. user-name to the IPP job-originating-user because the mapper may use its
own user-name with jobs.
NOTE: This specification does not specify how the LPD-to-IPP mapper 4. Mapping of LPD Control File Lines to IPP Parameters
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 This section describes the mapping from LPD control file lines (called
the Printer-queue-name operand supplied, since IPP provides no way to `functions') to IPP operation input parameters. The mapper receives the
cancel the current job. control file lines via the LPD receive-control-file sub-command.. Each
of the LPD functions appear as sub-sections of section 7 of RFC 1179.
There is no IPP equivalent for the LPD 'Remove jobs' command with a In LPD control file lines, the text operands have a maximum length of 31
User-name operand supplied, since IPP provides no way to cancel a job or 99 while IPP input parameters have a maximum of 255 characters.
specified by user name. Therefore, no data is lost.
The LPD-to-IPP mapper shall map a Cancel-Job operation to this command. The mapper converts each supported LPD function to its corresponding IPP
parameter as defined by tables in the subsections that follow. These
subsections group functions according to whether they are:
There are some major issues about setting the agent. . required with a job,
. optional with a job
. required with each document.
4. Mapping between LPD Sub-Commands and IPP Operations In the tables below, each LPD value is given a name, such as `h'. If an
IPP value uses the LPD value, then the IPP value column contains the LPD
name, such as `h' to denote this. Otherwise, the IPP value column
specifies the literal value.
This section describes the mapping between LPD sub-commands and IPP 4.1 Required Job Functions
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 () The following LPD functions MUST be in a received LPD job. The mapper
SHALL receive each of the following LPD functions and SHALL include the
information as a parameter with each IPP job. The functions SHOULD be in
the order `H', `P' and they SHOULD be the first two functions in the
control file, but they MAY be anywhere in the control file and in any
order.
Jacobs, Martin Expires January 30, 1998
Sub-command syntax: %x01 LPD function IPP
name value description name value
This sub-command is intended to abort any job transfer in process. If H h Originating Host h (in security layer)
an IPP Create-Job operation and/or a Send-Document operation were P u User identification u (in security layer)
performed on behalf of the receive job command that is being aborted, an none best-effort `true'
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 A mapper MAY sends its own host rather than the client's host, and a
closed before the job has been fully received. If so, that is an mapper MAY send its own user-name as user identification rather than the
alternate and simpler way to abort the job. client user. But in any case, the values sent SHALL be compatible with
the Cancel-Job operation. The IPP operation MAY have no way to specify
an originating host-name.
Mapping between LPD and IPP Protocols June 27, 1997 ISSUE: what do we do about job-orginating-host?
4.2 02 - Receive control file The mapper SHALL include best-effort=true so that it doesn't have to
determine which attributes a printer supports.
Sub-command syntax: %x02 Number-of-bytes-in-control-file, Name-of- 4.2 Optional Job Functions
control-file
This sub-command is roughly equivalent to the IPP Create-Job operation. The following LPD functions MAY be in a received job. These function
Once the control file has been has been received, it's contents should SHOULD follow the required job functions and precede the document
be translated, and an appropriate IPP Create-Job operation performed. functions, but they MAY be anywhere in the control file.
However, some information, such as Document-Name go in the Send-Document If the mapper receives such an LPD function, the mapper SHALL include
operation. the corresponding IPP attribute with the value converted as specified in
the table below. If the mapper does not receive such an LPD attribute,
the mapper SHALL NOT include the corresponding IPP attribute, except the
`L' LPD function whose absence has a special meaning as noted in the
table.
4.3 03 - Receive data file LPD function IPP
name value description name value
Sub-command syntax: %x03 Number-of-bytes-in-data-file Name-of-data-file J j Job name for job-name j
banner page
L l Print banner page job-sheets `standard' if `L' is
present
`none' if `L' is present
M m Mail When Printed notification- `job-completion'
events 'mailto://'m`@'h
notification-
method
Note: `m' is the user name and not an email address. The mapper can
fabricate an email address with the source host. This email address
mail fail when the `h' is some intermediary host that doesn't know about
user `m'. But there is no better solution.
This sub-command is roughly equivalent to the IPP Send-Document Jacobs, Martin Expires January 30, 1998
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 4.3 Required Document Functions
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 The mapper SHALL receive one set of the required document functions with
each copy of a document, and SHALL include the converted information as
parameters with each IPP document
This section describes the mapping from LPD control file lines to IPP If the control file contains required and recommended document
operation input parameters for the Print-Job, Create-Job, and Send- functions, the required functions SHOULD precede the recommended ones
Document operations. Each of the following sub-sections appear as sub- and if the job contains multiple documents, all the functions for each
sections of section 7 of RFC 1179. document are grouped together as shown in the example of section 6.3
"Required Document Functions". However, the document functions MAY be in
any order.
ISSUE: somewhere, we need to map the LPD query format to IPP attributes. LPD function IPP
name valu description name value
e
In LPD text operands have a maximum length of 31 or 99 while IPP input f fff Print formatted document-format 37 (langAutomatic)
parameters have a maximum of 255 characters. Therefore, no data is lost file
when mapping from LPD to IPP. However, when mapping from IPP to LPD, l fff Print file leaving document-format 37 (langAutomatic)
there may be some data loss if the IPP parameters exceed the maximum control characters
length of the LPD equivalent operands. o fff Print Postscript document-format 6 (langPS).
output file
copies see note
Note: In practice, the `f' LPD function is often overloaded. It is often
used with any format of document data including PostScript and PCL data.
In the following table, IPP input parameter names are indicated in Note: In practice, the `l' LPD function is often used as a rough
double quotes (") and input parameter values are indicated in single equivalent to the `f' function.
quotes ('). Values of the IPP "document-format" attribute that could be
registered, but are not currently, are indicated with "**".
Mapping between LPD and IPP Protocols June 27, 1997 Note: When RFC 1179 was written, no implementation supported the `o'
function; instead `f' was used for PostScript. Windows NT now sends `o'
function for a PostScript file.
Where there is a one-to-one mapping, both directions are specified. Note: the value `fff' of the `f', `l' and `o' functions is the name of
Where IPP has none, the LPD-to-IPP the attribute is ignored, and in the the data file as transferred, e.g. "dfA123woden".
IPP-to-LPD the LPD feature is left unspecified.
LPD command Equivalent IPP input parameter(s) If the mapper receives any other lower case letter, the mapper SHALL
reject the job because the document contains a format that the mapper
does not support.
C Class for banner None. The mapper determines the number of copies by counting the number of
page occurrences of each `fff' file with one of the lower-case functions
above. For example, if `f dfA123woden' occurs 4 times, then copies has a
value of 4. Although the LPD protocol allows the value of copies to be
different for each document, the commands and the receiving print
systems don't support this.
H Originating Host "job-originating-host" ISSUE: should we register DVI, ditroff and troff. At least DVI and one
of the troff is still in use.
I Indent Printing None. Jacobs, Martin Expires January 30, 1998
J Job name for banner "job-name" 4.4 Recommended Document Functions
page
L Print banner page "job-sheets" = any but 'none' The mapper SHOULD receive one set of the recommended document functions
Absence of an `L' directive with each document, and SHOULD include the converted information as
indicates that ``job-sheets=none'' parameters with each IPP document. The functions SHOULD be received in
is set. the order `U' and `N', but they MAY arrive in any order.
M Mail When Printed "notification-events" = 'job- LPD function IPP
completion' and "notification- name value description name value
method" = 'mailto://Job-
originating-user@job-originating-
host'
N Name of source file "document-name" This is on a per U fff ignored
data file basis N n Name of source file document-name n
P User identification "job-originating-user" Note: the value `fff' of the `U' function is the name of the data file
as transferred, e.g. "dfA123woden".
S Symbolic link data None. 5. Mapping from IPP operations to LPD commands
T Title for pr None. If the IPP-to-LPD mapper receives an IPP operation, the following table
summarizes the LPD command that it uses. Each section below gives the
detail. Each of the following sub-sections appear as sub-sections of
section 3 in the document "Internet Printing Protocol/1.0: Model and
Semantics" [1].
U Unlink data file None. IPP operation LPD command
W Width of output None. Get-Operations implemented by the mapper
Print-Job or Print-URI or receive-a-printer-job
Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs
Validate-Job implemented by the mapper
Cancel-Job remove-jobs
Get-Attributes (printer or job) send queue state (short or long)
or Get-Jobs
1 troff R font None. 5.1 Get-Operations
2 troff I font None. The mapper SHALL return a list of the operations that it supports. It
SHALL support at least those operations that are mandatory according to
the IPP model document [1].
3 troff B font None. 5.2 Print-Job
4 troff S font None. The mapper SHALL send the following commands in the order listed below:
Mapping between LPD and IPP Protocols June 27, 1997 . receive-a-printer-job command
. both receive-control-file sub-command and receive-data-file
sub-command
(unspecified order, see Note below)
. print-any-waiting-jobs command,
except that if the mapper is sending a sequence of receive-a-
Jacobs, Martin Expires January 30, 1998
printer-job commands, it MAY omit sending print-any-waiting-
jobs after any receive-a printer-job command that is neither
the first nor last command in this sequence
c Plot CIF file "document-format" = 'CIF' ** Note: it is recommended that the order of the receive-control-file sub-
command and the receive-data-file sub-command be configurable because
either order fails for some print systems. Some print systems assume
that the control file follows all data files and start printing
immediately on receipt of the control file. When such a print system
tries to print a data file that has not arrived, it produces an error.
Other print systems assume that the control file arrives before the data
files and start printing when the first data file arrives. Such a system
ignores the control information, such as banner page or copies.
d Print DVI file "document-format" = 'TeX DVI' ** NOTE: This specification does not define the mapping between the IPP
printer-uri and the LPD printer-name.
f Print formatted file "document-format" = 'Automatic' The mapper SHALL send the IPP parameters and attributes received from
the operation to the LPD printer by using the LPD receive-control-file
sub-command. The mapper SHALL create the job-number for use in the
control file name, but the receiving printer MAY, in some circumstances,
assign a different job-number to the job. The mapper SHALL create the
job-uri returned in the Print-Job response.
In practice, this value is often NOTE: This specification does not specify how the mapper determines the
overloaded. It is often used with job-number or the job-uri of a job that it creates nor does it specify
any format of document data the relation ship between the job-uri and the job-number, both of which
including PostScript and PCL data. the mapper creates.
g Plot file "document-format" = The mapper SHALL send data received in the IPP operation to the LPD
'BSDPlotLibrary' ** printer by using the LPD receive-data-file sub-command. The mapper SHALL
specify the exact number of bytes being transmitted in the number-of-
bytes field of the receive-data-file sub-command. It SHALL NOT use a
value of 0 in this field.
k reserved for None. If the mapper, while it is transmitting a receive-a-printer-job command
Kerberized clients or sub-command, either detects that its IPP connection has closed or
and servers This is unimplemented in LPD receives a Cancel-Job operation, the mapper SHALL terminate the LPD job
implementations. It was a place either with the abort sub-command or the remove-jobs command.
holder for future work that never
occurred.
l Print file leaving "document-format" = 'Automatic' ISSUE: error code conversion.
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' ** 5.3 Print-URI
file
o Print Postscript "document-format" = 'ps' The mapper SHALL handle this operation in the same way as a Print-Job
output file "document-format" = 'PS'(7) operation except that it SHALL obtain data referenced by the "document-
uri" parameter and SHALL then treat that data as if it had been received
via a Print-Job operation.
o is recognized by LPD-to-IPP, but Jacobs, Martin Expires January 30, 1998
never generated in IPP-to-LPD.
Rather `f' is used.
This was not implemented in any 5.4 Validate-Job
RFC-1179 implementations until
very recently in WinNT.
p Print file with 'pr' None. The mapper SHALL perform this operation directly. Because LPD supports
format very few attributes, this operation doesn't have much to check.
It therefore is equivalent to `f'
or `l'
Mapping between LPD and IPP Protocols June 27, 1997
r File to print with "document-format" = 'FORTRAN' ** 5.5 Create-Job
FORTRAN carriage
control
t Print troff output "document-format" = 'troff' ** The mapper SHALL handle this operation like Print-Job, except
file
v Print raster file "document-format" = 'RasterFormat' . the mapper SHALL send the control file after it has received
** the last Send-Document or Send-URI operation because the
control file contains all the document-name and document-
format values specified in the Send-Document and Send-URI
operations.
. the mapper SHALL perform one receive-data-file sub-command for
each Send-Document or Send-URI operation received and in the
same order received.
. the mapper SHALL send the control file either before all data
files or after all data files.
(See the note in the section on Print-Job about the dilemma of
sending the control file either before or after the data
files.
z reserved for future None. 5.6 Send-Document
use with the
Palladium print This was reserved for the MIT
system Palladium print system, but was
never used by that system.
6. Bibliography The mapper performs a receive-data-file sub-command on the received
data. See the preceding section 5.5 "Create-Job" for the details.
5.7 Send-URI
The mapper SHALL obtain the data referenced by the "document-uri"
parameter, and SHALL then treat that data as if it had been received via
a Send-Document operation. See the preceding section 5.6 "Send-Document"
for the details.
5.8 Cancel-Job
The mapper SHALL perform a remove-jobs command with the following
parameters:
. the printer is the one containing the job specified by the IPP
job-uri,
. the agent is the authenticated user-name of the IPP client,
. the job-number is the one corresponding to the IPP job-uri
parameter.
NOTE: This specification does not specify how the mapper maps the IPP
"job-uri" to the LPD printer-name or LPD job-number.
Jacobs, Martin Expires January 30, 1998
ISSUE: the model needs to offer a solution for mapping jobs to printers
either with a new job attribute "printer-uri" or with all operation
targets being a printer-uri.
5.9 Get-Attributes
LPD severely limits the set of attributes that the mapper is able to
return in its response for this operation.
When the mapper receives a Get-Attributes operation for a printer
object, it SHALL support, at most, the following printer attributes:
. printer-state
. printer-state-reasons
When the mapper receives a Get-Attributes operation for a job object, it
SHALL support, at most, the following job attributes:
. number-of-intervening-jobs
. job-originating-user
. job-uri
. job-originating-host
. document-name
. job-k-octets
. copies
The mapper uses either the long or short form of the "send queue state"
command. If it receives a request for the "job-originating-host" or
"copies" and supports those attribute it SHALL use the long form;
otherwise, it SHALL use the short form.
Note: the value of job-k-octets is the value in the short form, but it
can be computed from the copies and file size fields in the long form.
The mapper SHALL assume that the LPD response that it receives has the
format and information specified in section 3.3 "Send queue state
(short)" and section 3.4 "Send queue state (long)". The mapper SHALL
determine the value of each requested attribute by using the inverse of
the mapping specified in the two aforementioned sections.
Note: when the mapper receives the Get-Attributes operation for a
printer, it can determine the response from the printer-status line
without examining the rest of the LPD response. When the mapper receives
the Get-Attributes operation for a job and uses the LPD short form, it
can determine the response from the single line that pertains to the job
specified by the Get-Attributes operation.
NOTE: For Get-Attributes of a job, this specification does not specify
how the mapper maps the IPP "job-uri" to the LPD printer-name or LPD
job-number.
Jacobs, Martin Expires January 30, 1998
5.10 Get-Jobs
The mapper SHALL perform this operation in the same way as Get-
Attributes of a printer except that the mapper converts the job-lines,
and the IPP response contains one job object for each job in the LPD
response..
6. Mapping of IPP Parameters to LPD Control File Lines
This section describes the mapping from IPP operation input parameters
to LPD control file lines (called `functions'). The mapper receives the
IPP operation input parameters via the IPP operation. Each of the IPP
operation input parameters appear as sub-sections of section 3 and 4.2
in the IPP model document [1].
In the context of LPD control file lines, the text operands have a
maximum length of 31 or 99 while IPP input parameters have a maximum of
255 characters. Therefore, there may be some data loss if the IPP
parameters exceed the maximum length of the LPD equivalent operands.
The mapper converts each supported IPP parameter to its corresponding
LPD function as defined by tables in the subsections that follow. These
subsections group functions according to whether they are:
. required with a job,
. optional with a job
. required with each document.
In the tables below, each IPP value is given a name, such as `h'. If an
LPD value uses the IPP value, then the LPD value column contains the IPP
name, such as `h' to denote this. Otherwise, the LPD value column
specifies the literal value.
6.1 Required Job Functions
The mapper SHALL include the following LPD functions with each job, and
they SHALL have the specified value. They SHALL be the first functions
in the control file and they SHALL be in the order "H" and then "P".
IPP LPD function
name value name value description
(in security layer) h H gateway host Originating Host
(in security layer) u P u User identification
A mapper SHALL sends its own host rather than the client's host, because
some LPD systems require that it be the same as the host from which the
remove-jobs command comes. A mapper MAY send its own user name as user
identification rather than the client user. But in any case, the values
sent SHALL be compatible with the LPD remove-jobs operation.
Jacobs, Martin Expires January 30, 1998
6.2 Optional Job Functions
The mapper MAY include the following LPD functions with each job. They
SHALL have the specified value if they are sent. These functions, if
present, SHALL follow the require job functions, and they SHALL precede
the required document functions.
IPP attribute LPD function
name value nam value description
e
job-name j J j Job name for banner
page
job-sheets `standard' L u Print banner page
job-sheets `none' omit `L' function
notification- `job-completion' user Mail When Printed
user`@' M events `mailto://'
notification- host
method
Note: `L' has special meaning when it is omitted. If `M' is omitted,
there is no notification. If `J' is omitted, some undefined behavior
occurs with respect to the banner page.
Note: the `user' for the `M' function comes from a substring of the
notification-method's value.
6.3 Required Document Functions
The mapper SHALL include one set of the following LPD functions with
each document, and they SHALL have the specified values. For each
document, the order of the functions SHALL be `f', `U' and then `N',
where `f' is replicated once for each copy.
IPP attribute LPD function
name value name value description
document- `37' (langAutomatic) f fff Print formatted file
format or `6' (langPS).
copies c replicate `f' `c'
times
none U fff Unlink data file
document- n N n Name of source file
name
Note: the value `fff' of the `f' and `U' functions is the name of the
data file as transferred, e.g. "dfA123woden".
Note: the mapper SHALL not send the `o' function
ISSUE: should we register DVI, troff or ditroff?
Jacobs, Martin Expires January 30, 1998
If the mapper receives no "best-effort" or it has a value of false, then
the mapper SHALL reject the job if it specifies attributes or attribute
values that are not among those supported in the above tables.
Below is an example of the minimal control file for a job with three
copies of two files `foo' and `bar':
H tiger
P jones
f dfA123woden
f dfA123woden
f dfA123woden
U dfA123woden
N foo
f dfB123woden
f dfB123woden
f dfB123woden
U dfB123woden
N bar
7. References
[1] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet [1] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet
Printing Protocol/1.0: Model and Semantics", <draft-ietf-ipp-model- Printing Protocol/1.0: Model and Semantics", <draft-ietf-ipp-model-
02.txt>, July 1997. 02.txt>, July 1997.
[2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing [2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing
Protocol/1.0: Protocol specification", <draft-ietf-ipp-protocol-00.txt>, Protocol/1.0: Protocol specification", <draft-ietf-ipp-protocol-00.txt>,
July 1997. July 1997.
[3] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, August [3] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, August
1990. 1990.
[4] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., [4] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J.,
"Printer MIB", RFC 1759, March 1995. "Printer MIB", RFC 1759, March 1995.
[5] S. Bradner, "Key words for use in RFCs to Indicate Requirement [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 , March 1997 Levels", RFC 2119 , March 1997
[6] D. Crocker et al., ``ugmented BNF for Syntax Specifications: [6] D. Crocker et al., "Augmented BNF for Syntax Specifications: ABNF",
ABNF', draft-ietf-drums-abnf-02.txt. draft-ietf-drums-abnf-03.txt.
7. Author's Addresses 8. Author's Addresses
Thomas N. Hastings
Xerox Corporation
701 S. Aviation Blvd., ESAE-231
El Segundo, CA 90245
Phone: 310-333-6413 Robert Herriot (editor) Norm Jacobs
Fax: 310-333-5514 Sun Microsystems Inc. Sun Microsystems Inc.
EMail: hastings@cp10.es.xerox.com 901 San Antonio.Road., MPK-17 1430 Owl Ridge Rd.
Mapping between LPD and IPP Protocols June 27, 1997 Mountain View, CA 94043 Colorado Springs, CO 80919
Robert Herriot Phone: 650-786-8995 Phone: 719-532-9927
Sun Microsystems Inc. Fax: 650-786-7077 Fax: 719-535-0956
2550 Garcia Ave., MPK-17 Email: robert.herriot@eng.sun.com Email:
Mountain View, CA 94043 Norm.Jacobs@Central.sun.com
Jacobs, Martin Expires January 30, 1998
Phone: 415-786-8995 Thomas N. Hastings Jay Martin
Fax: 415-786-7077 Xerox Corporation Underscore, Inc.
Email: robert.herriot@eng.sun.com 701 S. Aviation Blvd., ESAE-231 41-C Sagamore Park Road
El Segundo, CA 90245 Hudson, NH 03051-4915
Norm Jacobs Phone: 310-333-6413 Phone: 603-889-7000
Sun Microsystems Inc. Fax: 310-333-5514 Fax: 603-889-2699
1430 Owl Ridge Rd. EMail: hastings@cp10.es.xerox.com Email: jkm@underscore.com
Colorado Springs, CO 80919
Phone: (719) 532-9927 9. Appendix A: ABNF Syntax for response of Send-queue-state (short)
Fax: (719) 535-0956
Email: Norm.Jacobs@Central.sun.com
Jay Martin The syntax in ABNF for the response to the LPD command `send-queue-state
Underscore Inc. (long)' is:
41-C Sagamore Park Rd.
Hudson, NH 03051-4915
Phone: (603) 889-7000 status-response = empty-queue / nonempty-queue
Fax: (603) 889-2600 empty-queue = "no-entries" LF
Email: jkm@underscore.com nonempty-queue = printer-status LF heading LF *(job LF)
printer-status = OK-status / error-status
OK-status = printer-name SP "ready and printing" LF
error-status = < implementation dependent status information >
heading = "Rank" 3SP Owner 6SP "Job" 13SP "Files"
23SP "Total Size" LF
; the column headings and their values below begin
at the columns
; 1, 8, 19, 35 and 63
job = rank *SP owner *SP job *SP files *SP total-size "bytes"
; jobs are in order of oldest to newest
rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
; job that is printing is "active"
; other values show position in the queue
owner = <user name of person who submitted the job>
job = 1*3DIGIT ; job-number
files = <file name> *( "," <file name>) ; truncated to 24 characters
total-size = 1*DIGIT ; combined size in bytes of all documents
10. Appendix B: ABNF Syntax for response of Send-queue-state (long)
The syntax in ABNF for the response to the LPD command `send-queue-state
(long)' is:
status-response = empty-queue / nonempty-queue
empty-queue = "no-entries" LF
nonempty-queue = printer-status LF *job
printer-status = OK-status / error-status
OK-status = printer-name SP "ready and printing" LF
error-status = < implementation dependent status information >
job = LF line-1 LF line-2 LF
line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
line-2 = file-name 1*SP document-size "bytes"
; jobs are in order of oldest to newest
rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
Jacobs, Martin Expires January 30, 1998
; job that is printing is "active"
; other values show position in the queue
owner = <user name of person who submitted the job>
job = 1*3DIGIT
file-name = [ 1*DIGIT "copies of" SP ] <file name>
; truncated to 24 characters
document-size = 1*DIGIT ;size of single copy of the document.
11. Appendix C: Unsupported LPD functions
The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper
ignores them and the IPP-to-LPD mapper does not send them.
LPD command
name description
C Class for banner page
I Indent Printing
S Symbolic link data
T Title for pr
W Width of output
1 troff R font
2 troff I font
3 troff B font
4 troff S font
The follow LPD functions specify document-formats which have no IPP
equivalent, unless someone registers them. The LPD-to-IPP mapper rejects
jobs that request such a document format, and the IPP-to-LPD mapper does
not send them.
LPD command
name description
c Plot CIF file
d Print DVI file
g Plot file
k reserved for Kerberized clients and servers
n Print ditroff output file
p Print file with 'pr' format
r File to print with FORTRAN carriage control
t Print troff output file
v Print raster file
z reserved for future use with the Palladium
print system
ISSUE: we may move some of these to the supported list.
Jacobs, Martin Expires January 30, 1998
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/