As per Relevance of the word document, we have this rfc below:
Network Working Group R.
Request For Comments: 2569 Xerox
Category: Experimental N.
Sun Microsystems, Inc
T.
Xerox
J.
Underscore, Inc
April 1999
Mapping between LPD and IPP
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
IESG
This document defines an Experimental protocol for the
community. The IESG expects that a revised version of this
will be published as Proposed Standard protocol. The
Standard, when published, is expected to change from the
defined in this memo. In particular, it is expected that
standards-track version of the protocol will incorporate
authentication and privacy features, and that an "ipp:" URL type
be defined which supports those security measures. Other changes
the protocol are also possible. Implementors are warned that
versions of this protocol may not interoperate with the version
IPP defined in this document, or if they do interoperate, that
protocol features may not be available
The IESG encourages experimentation with this protocol, especially
combination with Transport Layer Security (TLS) [RFC 2246], to
determine how TLS may effectively be used as a security layer
IPP
Herriot, et al. Experimental [Page 1]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
This document is one of a set of documents, which together
all aspects of a new Internet Printing Protocol (IPP). IPP is
application level protocol that can be used for distributed
using Internet tools and technologies. This document gives
advice to implementers of gateways between IPP and LPD (Line
Daemon). This document describes the mapping between (1) the
and operands of the 'Line Printer Daemon (LPD) Protocol' specified
RFC 1179 and (2) the operations, operation attributes and
template attributes of the Internet Printing Protocol/1.0 (IPP).
of the purposes of this document is to compare the functionality
the two protocols. Another purpose is to facilitate
of gateways between LPD and IPP
WARNING: RFC 1179 was not on the IETF standards track. While
1179 was intended to record existing practice, it fell short in
areas. However, this specification maps between (1) the
current practice of RFC 1179 and (2) IPP. This document does
attempt to map the numerous divergent extensions to the LPD
that have been made by many implementers
The full set of IPP documents includes
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for
Internet Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementors Guide [ipp-iig
Mapping between LPD and IPP Protocols (this document
The document, "Design Goals for an Internet Printing Protocol",
a broad look at distributed printing functionality, and it
real-life scenarios that help to clarify the features that need to
included in a printing protocol for the Internet. It
requirements for three types of users: end users, operators,
administrators. It calls out a subset of end user requirements
are satisfied in IPP/1.0. Operator and administrator requirements
out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol
the Internet Printing Protocol", describes IPP from a high
view, defines a roadmap for the various documents that form the
of IPP specifications, and gives background and rationale for
IETF working group's major decisions
Herriot, et al. Experimental [Page 2]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
The document, "Internet Printing Protocol/1.0: Model and Semantics",
describes a simplified model with abstract objects, their attributes
and their operations. It introduces a Printer and a Job object.
Job object supports multiple documents per Job. It also
security, internationalization, and directory issues
The document, "Internet Printing Protocol/1.0: Encoding
Transport", is a formal mapping of the abstract operations
attributes defined in the model document onto HTTP/1.1. It
the encoding rules for a new Internet media type called '
application/ipp'.
This document "Internet Printing Protocol/1.0: Implementer's Guide",
gives advice to implementers of IPP clients and IPP objects
TABLE OF
1. Introduction.....................................................4
2. Terminology......................................................5
3. Mapping from LPD Commands to IPP Operations......................5
3.1 Print any waiting jobs..........................................6
3.2 Receive a printer job...........................................6
3.2.1 Abort job.....................................................7
3.2.2 Receive control file..........................................7
3.2.3 Receive data file.............................................8
3.3 Send queue state (short)........................................8
3.4 Send queue state (long)........................................10
3.5 Remove jobs....................................................12
4. Mapping of LPD Control File Lines to IPP Operation and
Template Attributes.............................................13
4.1 Required Job Functions.........................................13
4.2 Optional Job Functions.........................................14
4.3 Required Document Functions....................................14
4.4 Recommended Document Functions.................................16
5. Mapping from IPP operations to LPD commands.....................16
5.1 Print-Job......................................................16
5.2 Print-URI......................................................18
5.3 Validate-Job...................................................18
5.4 Create-Job.....................................................18
5.5 Send-Document..................................................18
5.6 Send-URI.......................................................18
5.7 Cancel-Job.....................................................18
5.8 Get-Printer-Attributes.........................................19
5.9 Get-Job-Attributes.............................................19
5.10 Get-Jobs......................................................20
6. Mapping of IPP Attributes to LPD Control File Lines.............20
6.1 Required Job Functions.........................................21
6.2 Optional Job Functions.........................................21
Herriot, et al. Experimental [Page 3]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
6.3 Required Document Functions....................................22
7. Security Considerations.........................................23
8. References......................................................23
9. Authors' Addresses..............................................24
10.Appendix A: ABNF Syntax for response of Send-queue-state (short)25
11.Appendix B: ABNF Syntax for response of Send-queue-state (long) 26
12.Appendix C: Unsupported LPD functions...........................27
13.Full Copyright Statement........................................28
1.
The reader of this specification is expected to be familiar with
IPP Model and Semantics specification [RFC2566], the IPP Encoding
Transport [RF2565], and the Line Printer Daemon (LPD)
specification [RFC1179] as described in RFC 1179.
RFC 1179 was written in 1990 in an attempt to document existing
protocol implementations. Since then, a number of
extensions have been made by vendors to support
specific to their printing solutions. All of these
consist of additional control file commands. This document does
address any of these vendor extensions. Rather it addresses
practice within the context of the features described by RFC 1179.
Deviations of existing practice from RFC 1179 are so indicated
Other LPD control file commands in RFC 1179 are obsolete. They
intended to work on "text" only formats and are inappropriate
many contemporary document formats that completely specify each page
This document does not address the support of these
features
In the area of document formats, also known as page
languages (PDL), RFC 1179 defines a fixed set with no capability
extension. Consequently, some new PDL's are not supported, and
of those that are supported are sufficiently unimportant now
they have not been registered for use with the Printer MIB [RFC1759]
and IPP [RFC2566] [RFC2565], though they could be registered
desired. See the Printer MIB specification [RFC1759] and/or the
Model specification [RFC2566] for instructions for registration
document-formats with IANA. IANA lists the registered document
formats as "printer languages".
This document addresses the protocol mapping for both directions
mapping of the LPD protocol to the IPP protocol and mapping of
IPP protocol to the LPD protocol. The former is called the "LPD-to
IPP mapper" and the latter is called the "IPP-to-LPD mapper".
Herriot, et al. Experimental [Page 4]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
This document is an informational document that is not on
standards track. It is intended to help implementers of
between IPP and LPD. It also provides an example, which
additional insight into IPP
2.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 1179 uses the word "command" in two contexts: for over-the-
operations and for command file functions. This document SHALL
the word "command" for the former and the phrase "functions" for
latter. The syntax of the LPD commands is given using
[RFC2234].
The following tokens are used in order to make the syntax
readable
LF stands for %x0A (linefeed
SP stands for %x20. (space
DIGIT stands for %x30-39 ("0" to "9")
3. Mapping from LPD Commands to IPP
This section describes the mapping from LPD commands to
operations. Each of the following sub-sections appear as sub
sections of section 5 of RFC 1179.
The following table summarizes the IPP operation that the mapper
when it receives an LPD command. Each section below gives
detail
LPD command IPP
print-any-waiting-jobs
receive-a-printer-job Print-Job or Create-Job/Send-
send queue state Get-Printer-Attributes and Get-
(short or long
remove-jobs Cancel-
Herriot, et al. Experimental [Page 5]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
3.1 Print any waiting
Command syntax
print-waiting-jobs = %x01 printer-name
This command causes the LPD daemon check its queue and print
waiting jobs. An IPP printer handles waiting jobs without such
nudge
If the mapper receives this LPD command, it SHALL ignore it and
no IPP operation
3.2 Receive a printer
Command syntax
receive-job = %x02 printer-name
The control file and data files mentioned in the following
are received via LPD sub-commands that follow this command.
mapping to IPP commands and attributes is described later in
section
The mapper maps the 'Receive a printer job' command to either
- the Print-Job operation which includes a single data file
- the Create-Job operation followed by one Send-Document
for each data file
If the IPP printer supports both Create-Job and Send-Document, and
a job consists of
- a single data file, the mapper SHOULD use the Print-
operation, but MAY use the Create-Job and Send-
operations
- more than one data file, the mapper SHALL use Create-
followed by one Send-Document for each received LPD data file
If the IPP printer does not support both Create-Job and Send
Document, and if a job consists of
- a single data file, the mapper SHALL use the
operation
- more than one data file, the mapper SHALL submit each
LPD data file as a separate Print-Job operation (
converting a single LPD job into multiple IPP jobs).
Herriot, et al. Experimental [Page 6]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
If the mapper uses Create-Job and Send-Document, it MUST send
Create-Job operation before it sends any Send-Document
whether the LPD control file, which supplies attributes for Create
Job, arrives before or after all LPD data files
NOTE: This specification does not specify how the mapper maps:
LPD Printer-name operand to the IPP "printer-uri"
attribute
The following three sub-sections gives further details about
mapping from LPD receive-a-printer-job sub-commands. Each of
following subsections appear as sub-sections of section 6 of
1179.
3.2.1 Abort
Sub-command syntax
abort-job = %x1
This sub-command of receive-a-printer-job is intended to abort
job transfer in process
If the mapper receives this sub-command, it SHALL cancel the job
it is in the process of transmitting
If the mapper is in the process of sending a Print-Job or Create-
operation, it terminates the job either by closing the connection,
performing the Cancel-Job operation with the job-uri that it
from the Print-Job or Create-Job operation
NOTE: This sub-command is implied if at any time the
between the LPD client and server is terminated before an
print job has been transferred via an LPD Receive-a-printer-
request
3.2.2 Receive control
Sub-command syntax
receive-control-file = %x2 number-of-bytes SP name-of-control-file
number-of-bytes = 1*
name-of-control-file = "cfA" job-number client-host-
; e.g. "cfA123woden
job-number = 3
client-host-name =
Herriot, et al. Experimental [Page 7]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
This sub-command is roughly equivalent to the IPP Create-
operation
The mapper SHALL use the contents of the received LPD control file
create IPP operation attribute and job template attribute values
transmit with the Print-Job or Create-Job operation
3.2.3 Receive data
Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-
receive-data-file = %x03 number-of-bytes SP name-of-data-file
number-of-bytes = 1*
name-of-data-file = "df" letter job-number client-host-
; e.g. "dfA123woden for the first
letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z
; first file is "A",
; second "B", and 52nd file is "z
job-number = 3
client-host-name =
This sub-command is roughly equivalent to the IPP Send-
operation
The mapper SHALL use the contents of the received LPD data file
the data to transmit with the IPP Print-Job or Send-
operation
Although RFC 1179 alludes to a method for passing an
length data file by using an octet-count of zero, no
support this feature. The mapper SHALL reject a job that has a
of 0 in the number-of-bytes field
3.3 Send queue state (short
Command syntax
send-queue-short = %x03 printer-name *(SP(user-name / job-number))
The mapper's response to this command includes information about
printer and its jobs. RFC 1179 specifies neither the information
the format of its response. This document requires the mapper
follow existing practice as specified in this document
The mapper SHALL produce a response in the following format
consists of a printer-status line optionally followed by a
line, and a list of jobs. This format is defined by examples below
Appendix A contains the ABNF syntax
Herriot, et al. Experimental [Page 8]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
For an printer with no jobs, the response starts in column 1 and is
no
For a printer with jobs, an example of the response is
killtree is ready and
Rank Owner Job Files Total
active fred 123 stuff 1204
1st smith 124 resume, foo 34576
2nd fred 125 more 99
3rd mary 126 mydoc 378
4th jones 127 statistics.ps 4567
5th fred 128 data.txt 9
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
attribute
LPD field IPP attribute special conversion
printer- printer-state and For a printer-state of idle
status printer-state-reasons processing, the mapper SHALL
the formats above. For stopped
the mapper SHALL use printer
state-reasons to produce
unspecified format for the error
rank number-of- the mapper SHALL the format
intervening-
owner job-originating-user- unspecified conversion; job
name originating-user-name may be
mapper's user-
job job-id the mapper shall use the job-
files document-name the mapper shall create a
separated list of the document
names and then truncate this
to the first 24
total- job-k- the mapper shall multiple
size octets*copies*1024 value of job-k-octets by 1024
by the value of the "copies
attribute
Herriot, et al. Experimental [Page 9]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
A mapper SHOULD use the job attribute number-of-intervening-
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
printer doesn't support the job attribute number-of-intervening-jobs
a mapper MAY use the job's position
Note: a Printer may set the value of job-originating-user-name to
authenticated user or to the value of "requesting-user-name",
depending on the implementation and configuration. For a gateway,
authenticated user is the user-id of the gateway, but
"requesting-user-name" may contain the name of the user who is
gateway's client
In order to obtain the information specified above, The LPD-to-
mapper SHALL use the Get-Printer-Attributes operation to
printer-status and SHOULD use the Get-Jobs operation to
information about all of the jobs. If the LPD command contains job
numbers or user-names, the mapper MAY handle the filtering of
response. If the LPD command contains job-numbers but no user-names
the mapper MAY use Get-Job-Attributes on each converted job-
rather than Get-Jobs. If the LPD command contains a single user-
but no job-numbers, the mapper MAY use Get-Jobs with the my-
option if the server supports this option and if the server
the client to be a proxy for the LPD user
NOTE: This specification does not define how the mapper maps the
Printer-name operand to the IPP "printer-uri" operation attribute
3.4 Send queue state (long
Command syntax
send-queue-long = %x04 printer-name *(SP(user-name / job-number))
The mapper's response to this command includes information about
printer and its jobs. RFC 1179 specifies neither the information
the format of its response. This document requires the mapper
follow existing practice as specified in this document
The mapper SHALL produce a response in the following format
consists of a printer-status line optionally followed a list of jobs
where each job consists of a blank line, a description line, and
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
Herriot, et al. Experimental [Page 10]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
For an printer with no jobs the response is
no
For a printer with jobs, an example of the response is
killtree is ready and
fred: active [job 123 tiger
2 copies of stuff 602
smith: 1st [job 124 snail
2 copies of resume 7088
2 copies of foo 10200
fred: 2nd [job 125 tiger
more 99
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
the short form, their fields are identical except for a) the
and host fields which are only in the long form, and b) the "size
field contains the single copy size of each file. Thus the sum
the file sizes in the "size" field times the value of the "copies
field produces the value for the "Total Size" field in the
form. For fields other than the host and copies fields, see
preceding section. For the host field see the table below
LPD field IPP attribute special conversion
host unspecified conversion; job
originating-host may be
mapper's
copies copies the mapper shall assume
value of copies precedes
string "copies of "; otherwise
the value of copies is 1.
NOTE: This specification does not define how the mapper maps the
Printer-name operand to the IPP printer-uri operation attribute
Herriot, et al. Experimental [Page 11]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
3.5 Remove
Command syntax
remove-jobs = %x05 printer-name SP
*(SP(user-name / job-number))
The agent operand is the user-name of the user initiating
remove-jobs command. The special user-name 'root' indicates
privileged user who can remove jobs whose user-name differs from
agent
The mapper SHALL issue one Cancel-Job operation for each
referenced by the remove-jobs command. Each job-number in
remove-jobs command references a single job. Each user-name in
remove-jobs command implicitly references all jobs owned by
specified user. The active job is implicitly referenced when
remove-jobs command contains neither job-numbers nor user-names.
mapper MAY use Get-Jobs to determine the job-uri of
referenced jobs
The mapper SHALL not use the agent name of 'root' when end-
cancel their own jobs. Violation of this rule creates a
security violation, and it may cause the printer to issue
notification that misleads a user into thinking that some
person canceled the job
If the agent of a remove-jobs command for a job J is the same as
user name specified with the 'P' function in the control file for
J, then the mapper SHALL ensure that the initiator of the Cancel-
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
the receiver perceives as the initiator of IPP operations. The
either acts as itself or acts on behalf of another user. The
is preferable if it is possible. This consistency is
between Print-Job/Create-Job and Cancel-Job in order for Cancel-
to work, but it is also desirable for other operations. For example
Get-Jobs may give more information about job submitted by
initiator of this operation
NOTE: This specification does not define how the mapper maps: (1)
LPD printer-name to the IPP "printer-uri" or (2) the LPD job-
to the IPP "job-uri".
NOTE: This specification does not specify how the mapper maps the
user-name to the IPP job-originating-user because the mapper may
its own user-name with jobs
Herriot, et al. Experimental [Page 12]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
4. Mapping of LPD Control File Lines to IPP Operation and Job
This section describes the mapping from LPD control file
(called 'functions') to IPP operation attributes and job
attributes. The mapper receives the control file lines via the
receive-control-file sub-command. Each of the LPD functions
as sub-sections of section 7 of RFC 1179.
In LPD control file lines, the text operands have a maximum length
31 or 99 while IPP operation attribute and job template
values have a maximum of 255 or 1023 octets, depending on
attribute syntax. Therefore, no data is lost
The mapper converts each supported LPD function to its
IPP operation or job template attribute as defined by tables in
subsections that follow. These subsections group functions
to whether they are
- required with a job
- optional with a
- required with each document
In the tables below, each LPD value is given a name, such as 'h'.
an IPP value uses the LPD value, then the IPP value column
the LPD name, such as 'h' to denote this. Otherwise, the IPP
column specifies the literal value
4.1 Required Job
The following LPD functions MUST be in a received LPD job. The
SHALL receive each of the following LPD functions and SHALL
the information as a operation or job template attribute with
IPP job. The functions SHOULD be in the order 'H', 'P' and
SHOULD be the first two functions in the control file, but they
be anywhere in the control file and in any order
LPD function
name value description name
H h Originating Host h (in security layer
P u User identification requesting- u (and in
user-name layer
none ipp- 'true
attribute
Herriot, et al. Experimental [Page 13]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
A mapper MAY send its own host rather than the client's host, and
mapper MAY send its own user-name as user identification rather
the client user. But in any case, the values sent SHALL be
with the Cancel-Job operation. The IPP operation MAY have no way
specify an originating host-name
The mapper SHALL include ipp-attribute-fidelity = true so that
doesn't have to determine which attributes a printer supports
4.2 Optional Job
The following LPD functions MAY be present in a received job.
functions SHOULD follow the required job functions and precede
document functions, but they MAY be anywhere in the control file
If the mapper receives such an LPD function, the mapper SHALL
the corresponding IPP attribute with the value converted as
in the table below. If the mapper does not receive such an
attribute, the mapper SHALL NOT include the corresponding
attribute, except the 'L' LPD function whose absence has a
meaning as noted in the table
LPD function
name value description name
J j Job name for job-name
banner
L l Print banner page job-sheets 'standard' if 'L'
'none' if 'L' is
M m Mail When Printed IPP has no
mechanism. To
this LPD feature,
gateway must poll
the Get-Job-
operation
4.3 Required Document
The mapper SHALL receive one set of the required document
with each copy of a document, and SHALL include the
information as operation or job template attributes with each
document
If the control file contains required and recommended
functions, the required functions SHOULD precede the recommended
and if the job contains multiple documents, all the functions
Herriot, et al. Experimental [Page 14]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
each document are grouped together as shown in the example of
6.3 "Required Document Functions". However, the document
MAY be in any order
LPD function
name value description name
f fff Print formatted document-format 'application/octet
file stream
l fff Print file leaving document-format 'application/octet
control characters stream
o fff Print Postscript document-format 'application/
output file pt
copies see
Note: In practice, the 'f' LPD function is often overloaded. It
often used with any format of document data including PostScript
PCL data
Note: In practice, the 'l' LPD function is often used as a
equivalent to the 'f' function
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
Note: the value 'fff' of the 'f', 'l' and 'o' functions is the
of the data file as transferred, e.g. "dfA123woden".
If the mapper receives any other lower case letter, the mapper
reject the job because the document contains a format that the
does not support
The mapper determines the number of copies by counting the number
occurrences of each 'fff' file with one of the lower-case
above. For example, if 'f dfA123woden' occurs 4 times, then
has a value of 4. Although the LPD protocol allows the value
copies to be different for each document, the commands and
receiving print systems don't support this
Herriot, et al. Experimental [Page 15]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
4.4 Recommended Document
The mapper SHOULD receive one set of the recommended
functions with each document, and SHOULD include the
information as an operation or job template attribute with each
document. The functions SHOULD be received in the order 'U' and 'N',
but they MAY arrive in any order
LPD function
name value description name
U fff
N n Name of source file document-name
Note: the value 'fff' of the 'U' function is the name of the
file as transferred, e.g. "dfA123woden".
5. Mapping from IPP operations to LPD
If the IPP-to-LPD mapper receives an IPP operation, the
table summarizes the LPD command that it uses. Each section
gives the detail. Each of the following sub-sections appear as sub
sections of section 3 in the document "Internet
Protocol/1.0: Model and Semantics" [RFC2566].
IPP operation LPD
Print-Job or Print-URI or receive-a-printer-
Create-Job/Send-Document/Send-URI and then print-any-waiting-
Validate-Job implemented by the
Cancel-Job remove-
Get-Printer-Attributes, Get-Job- send queue state (short or long
Attributes or Get-
5.1 Print-
The mapper SHALL send the following commands in the order
below
- receive-a-printer-job
- both receive-control-file sub-command and receive-data-
sub-command (unspecified order, see Note below
- print-any-waiting-jobs command, except that if the mapper
sending a sequence of receive a printer-job commands, it
omit sending print-any-waiting-jobs after any receive
printer-job command that is neither the first nor last
in this
Herriot, et al. Experimental [Page 16]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
Note: it is recommended that the order of the receive-control-
subcommand and the receive-data-file sub-command be
because either order fails for some print systems. Some print
assume that the control file follows all data files and
printing immediately on receipt of the control file. When such
print system tries to print a data file that has not arrived,
produces an error. Other print systems assume that the control
arrives before the data files and start printing when the first
file arrives. Such a system ignores the control information, such
banner page or copies
NOTE: This specification does not define the mapping between the
printer-uri and the LPD printer-name
The mapper SHALL send the IPP operation attributes and job
attributes received from the operation to the LPD printer by
the LPD receive-control-file sub-command. The mapper SHALL create
LPD job-number for use in the control file name, but the
printer MAY, in some circumstances, assign a different job-number
the job. The mapper SHALL create the IPP job-id and IPP job-
returned in the Print-Job response
NOTE: This specification does not specify how the mapper
the LPD job-number, the IPP job-id or the IPP job-uri of a job
it creates nor does it specify the relationship between the IPP job
uri, IPP the job-id and the LPD job-number, both of which the
creates. However, it is likely that the mapper will use the
integer value for both the LPD job-number and the IPP job-id,
that the IPP Job-uri is the printer's URI with the job-
concatenated on the end
The mapper SHALL send data received in the IPP operation to the
printer by using the LPD receive-data-file sub-command. The
SHALL specify the exact number of bytes being transmitted in
number-of-bytes field of the receive-data-file sub-command. It
NOT use a value of 0 in this field
If the mapper, while it is transmitting a receive-a-printer-
command or sub-command, either detects that its IPP connection
closed or receives a Cancel-Job operation, the mapper SHALL
the LPD job either with the abort sub-command or the remove-
command
This document does not address error code conversion
Herriot, et al. Experimental [Page 17]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
5.2 Print-
The mapper SHALL handle this operation in the same way as a Print-
operation except that it SHALL obtain data referenced by
"document-uri" operation attribute and SHALL then treat that data
if it had been received via a Print-Job operation
5.3 Validate-
The mapper SHALL perform this operation directly. Because
supports very few attributes, this operation doesn't have much
check
5.4 Create-
The mapper SHALL handle this operation like Print-Job, except
- the mapper SHALL send the control file after it has received
last Send-Document or Send-URI operation because the
file contains all the document-name and document-format
specified in the Send-Document and Send-URI operations
- the mapper SHALL perform one receive-data-file sub-command
each Send-Document or Send-URI operation received and in
same order received
- the mapper SHALL send the control file either before all
files or after all data files. (See the note in the section
Print-Job about the dilemma of sending the control file
before or after the data files
5.5 Send-
The mapper performs a receive-data-file sub-command on the
data. See the preceding section 5.4 "Create-Job" for the details
5.6 Send-
The mapper SHALL obtain the data referenced by the "document-uri
operation attribute, and SHALL then treat that data as if it had
received via a Send-Document operation. See the preceding section 5.5
"Send-Document" for the details
5.7 Cancel-
The mapper SHALL perform a remove-jobs command with the
operation attributes
Herriot, et al. Experimental [Page 18]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
- the printer is the one to which the job was submitted, that
the IPP printer-uri is mapped to an LPD printer-name by the
mechanism as for all
- the agent is the authenticated user-name of the IPP
- the job-number is the job-id returned by the Print-Job command
that is, the LPD job-number has the same value as the IPP job-
for likely
5.8 Get-Printer-
LPD severely limits the set of attributes that the mapper is able
return in its response for this operation. The mapper SHALL support
at most, the following printer attributes
- printer-
- printer-state-
The mapper uses either the long or short form of the "send
state" command
The mapper SHALL assume that the LPD response that it receives
the format and information specified in section 3.3 "Send queue
(short)" and section 3.4 "Send queue state (long)". The mapper
determine the value of each requested attribute by using the
of the mapping specified in the two aforementioned sections
Note: the mapper can determine the response from the printer-
line without examining the rest of the LPD response
5.9 Get-Job-
LPD severely limits the set of attributes that the mapper is able
return in its response for this operation. The mapper SHALL support
at most, the following job attributes
- number-of-intervening-
- job-originating-user-
- job-
- document-
- job-k-
-
The mapper uses either the long or short form of the "send
state" command. If it receives a request for the "job-k-octets"
"copies" and supports the attribute it SHALL use the long form
otherwise, it SHALL use the short form
Herriot, et al. Experimental [Page 19]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
Note: the value of job-k-octets is the value in the short
divided by the number of "copies" which is on the long form only.
value can also be determined by adding the "size" field values
each document in the job in the long form
The mapper SHALL assume that the LPD response that it receives
the format and information specified in section 3.3 "Send queue
(short)" and section 3.4 "Send queue state (long)". The mapper
determine the value of each requested attribute by using the
of the mapping specified in the two aforementioned sections
Note: when the mapper uses the LPD short form, it can determine
response from the single LPD line that pertains to the job
by the Get-Job-Attributes operation
Note: the mapper can use its correspondence between the IPP job-id
job-uri and the LPD job-number
5.10 Get-
The mapper SHALL perform this operation in the same way as Get-Job
Attributes except that the mapper converts all the LPD job-lines,
the IPP response contains one job object for each job-line in the
response
6. Mapping of IPP Attributes to LPD Control File
This section describes the mapping from IPP operation attributes
job template attributes to LPD control file lines (called '
functions'). The mapper receives the IPP operation attributes and
template atributes via the IPP operation. Each of the IPP
attributes and job template attributes appear as sub-sections
section 3 and 4.2 in the IPP model document [RFC2566].
In the context of LPD control file lines, the text operands have
maximum length of 31 or 99 while IPP operation attributes and
template attributes have a maximum of 255 or 1023 octets,
on the attribute syntax. Therefore, there may be some data loss
the IPP operation attribute and job template attribute values
the maximum length of the LPD equivalent operands
The mapper converts each supported IPP operation attribute and
template attribute to its corresponding LPD function as defined
tables in the subsections that follow. These subsections
functions according to whether they are
Herriot, et al. Experimental [Page 20]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
- required with a job
- optional with a
- required with each document
In the tables below, each IPP value is given a name, such as 'h'.
an LPD value uses the IPP value, then the LPD value column
the IPP name, such as 'h' to denote this. Otherwise, the LPD
column specifies the literal value
6.1 Required Job
The mapper SHALL include the following LPD functions with each job
and they SHALL have the specified value. They SHALL be the
functions in the control file and they SHALL be in the order "H"
then "P".
IPP LPD
name value name value
(perhaps in security h H gateway host Originating
layer
requesting-user-name u P u User
and in the
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
which the remove-jobs command comes. A mapper MAY send its own
name as user identification rather than the client user. But in
case, the values sent SHALL be compatible with the LPD remove-
operation
6.2 Optional Job
The mapper MAY include the following LPD functions with each job
They SHALL have the specified value if they are sent.
functions, if present, SHALL follow the require job functions,
they SHALL precede the required document functions
IPP attribute LPD
name value name value
job-name j J j Job name for
job-sheets 'standard' L u Print banner
job-sheets 'none' omit 'L'
Herriot, et al. Experimental [Page 21]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
Note: 'L' has special meaning when it is omitted. If 'J' is omitted
some undefined behavior occurs with respect to the banner page
6.3 Required Document
The mapper SHALL include one set of the following LPD functions
each document, and they SHALL have the specified values. For
document, the order of the functions SHALL be 'f', 'U' and then 'N',
where 'f' is replicated once for each copy
IPP attribute LPD
name value name value
document- 'application/octet- f fff Print formatted
format stream'
'application/PostScript
copies c replicate 'f' 'c
none U fff Unlink data
document- n N n Name of source
Note: the value 'fff' of the 'f' and 'U' functions is the name of
data file as transferred, e.g. "dfA123woden".
Note: the mapper SHALL not send the 'o'
ISSUE: should we register DVI, troff or ditroff
If the mapper receives no "ipp-attribute-fidelitybest-effort" or
has a value of false, then the mapper SHALL reject the job if
specifies attributes or attribute values that are not among
supported in the above tables
Below is an example of the minimal control file for a job with
copies of two files 'foo' and 'bar':
H
P
f dfA123
f dfA123
f dfA123
U dfA123
N
f dfB123
f dfB123
f dfB123
Herriot, et al. Experimental [Page 22]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
U dfB123
N
7. Security
There are no security issues beyond those covered in the IPP
and Transport document [RFC2565], the IPP model document [RFC2566]
and the LPD document [RFC1179].
8.
[ipp-iig] Hasting, T., et al., "Internet Printing Protocol/1.0:
Implementer's Guide", Work in Progress
[RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J
Gyllenskog, "Printer MIB", RFC 1759, March 1995.
[RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
August 1990.
[RFC2119] Bradner, S. "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] D. Crocker et al., "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "
Printing Protocol/1.0: Encoding and Transport", RFC 2565,
April 1999.
[RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P
Powell, "Internet Printing Protocol/1.0: Model
Semantics", RFC 2566, April 1999.
[RFC2567] Wright, D., "Design Goals for an Internet
Protocol", RFC 2567, April 1999.
[RFC2568] Zilles, S., "Rationale for the Structure and Model
Protocol for the Internet Printing Protocol", RFC 2568,
April 1999.
Herriot, et al. Experimental [Page 23]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
9. Authors'
Robert Herriot (Editor
Xerox
3400 Hillview Ave., Bldg #1
Palo Alto, CA 94304
Phone: 650-813-7696
Fax: 650-813-6860
EMail: rherriot@pahv.xerox.
Norm
Sun Microsystems Inc
1430 Owl Ridge Rd
Colorado Springs, CO 80919
Phone: 719-532-9927
Fax: 719-535-0956
EMail: Norm.Jacobs@Central.sun.
Thomas N.
Xerox
701 S. Aviation Blvd., ESAE-231
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.
Jay
Underscore, Inc
41-C Sagamore Park
Hudson, NH 03051-4915
Phone: 603-889-7000
Fax: 603-889-2699
EMail: jkm@underscore.
Herriot, et al. Experimental [Page 24]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
10. Appendix A: ABNF Syntax for response of Send-queue-state (short
The syntax in ABNF for the response to the LPD command 'send-queue
state (long)' is
status-response = empty-queue / nonempty-
empty-queue = "no-entries"
nonempty-queue = printer-status LF heading LF *(job LF
printer-status = OK-status / error-
OK-status = printer-name SP "ready and printing"
error-status = < implementation dependent status information >
heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files
23SP "Total Size"
; the column headings and their values below
at the
; 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
rank = "active" / "1st" / "2nd" / "3rd" / integer "th
; job that is printing is "active
; other values show position in the
owner =
job = 1*3DIGIT ; job-
files = *( "," ) ; truncated to 24
total-size = 1*DIGIT ; combined size in bytes of all
Herriot, et al. Experimental [Page 25]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
11. 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-
empty-queue = "no-entries"
nonempty-queue = printer-status LF *
printer-status = OK-status / error-
OK-status = printer-name SP "ready and printing"
error-status = < implementation dependent status information >
job = LF line-1 LF line-2
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
rank = "active" / "1st" / "2nd" / "3rd" / integer "th
; job that is printing is "active
; other values show position in the
owner =
job = 1*3
file-name = [ 1*DIGIT "copies of" SP ]
; truncated to 24
document-size = 1*DIGIT ;size of single copy of the document
Herriot, et al. Experimental [Page 26]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
12. Appendix C: Unsupported LPD
The follow LPD functions have no IPP equivalent. The LPD-to-
mapper ignores them and the IPP-to-LPD mapper does not send them
LPD
name
C Class for banner
I Indent
H Host of
M Mail when
S Symbolic link
T Title for
W Width of
1 troff R
2 troff I
3 troff B
4 troff S
The follow LPD functions specify document-formats which have no
equivalent, unless someone registers them. The LPD-to-IPP
rejects jobs that request such a document format, and the IPP-to-
mapper does not send them
LPD
name
c Plot CIF
d Print DVI
g Plot
k reserved for Kerberized clients and
n Print ditroff output
p Print file with 'pr'
r File to print with FORTRAN carriage
t Print troff output
v Print raster
z reserved for future use with the
print
Herriot, et al. Experimental [Page 27]
RFC 2569 Mapping between LPD and IPP Protocols April 1999
13. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Herriot, et al. Experimental [Page 28]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
