idnits 2.17.1
draft-ietf-ipp-lpd-ipp-map-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 25
longer pages, the longest (page 20) being 65 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 203 has weird spacing: '...ommands to IP...'
== Line 227 has weird spacing: '...If the mapper...'
== Line 245 has weird spacing: '...ate-Job opera...'
== Line 252 has weird spacing: '...AY use the ...'
== Line 260 has weird spacing: '... single data ...'
== (28 more instances...)
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHALL not' in this paragraph:
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.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHALL not' in this paragraph:
Note: the mapper SHALL not send the 'o' function
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (November 16, 1998) is 9293 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT Robert Herriot (editor)
3 Sun Microsystems, Inc.
4 draft-ietf-ipp-lpd-ipp-map-05.txt Tom Hastings
5 Xerox Corporation
6 Norm Jacobs
7 Sun Microsystems, Inc.
8 Jay Martin
9 Underscore, Inc.
10 November 16, 1998
12 Mapping between LPD and IPP Protocols
14 Status of this Memo
16 This document is an Internet-Draft. Internet-Drafts are working
17 documents of the Internet Engineering Task Force (IETF), its areas, and
18 its working groups. Note that other groups may also distribute working
19 documents as Internet-Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference material
24 or to cite them other than as "work in progress."
26 To learn the current status of any Internet-Draft, please check the
27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
29 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
30 ftp.isi.edu (US West Coast).
32 Copyright (C)The Internet Society (1998). All Rights Reserved.
34 Abstract
36 This document is one of a set of documents, which together describe all
37 aspects of a new Internet Printing Protocol (IPP). IPP is an application
38 level protocol that can be used for distributed printing using Internet
39 tools and technologies. This document gives some advice to implementers
40 of gateways between IPP and LPD (Line Printer Daemon). This document
41 describes the mapping between (1) the commands and operands of the 'Line
42 Printer Daemon (LPD) Protocol' specified in RFC 1179 and (2) the
43 operations, operation attributes and job template attributes of the
44 Internet Printing Protocol/1.0 (IPP). One of the purposes of this
45 document is to compare the functionality of the two protocols. Another
46 purpose is to facilitate implementation of gateways between LPD and IPP.
48 WARNING: RFC 1179 was not on the IETF standards track. While RFC 1179
49 was intended to record existing practice, it fell short in some areas.
50 However, this specification maps between (1) the actual current practice
51 of RFC 1179 and (2) IPP. This document does not attempt to map the
52 numerous divergent extensions to the LPD protocol that have been made by
53 many implementers.
55 Jacobs, Martin Expires May 16, 1999
56 The full set of IPP documents includes:
58 Design Goals for an Internet Printing Protocol [ipp-req]
59 Rationale for the Structure and Model and Protocol for the Internet
60 Printing Protocol [ipp-rat]
61 Internet Printing Protocol/1.0: Model and Semantics [ipp mod]
62 Internet Printing Protocol/1.0: Encoding and Transport [ipp-pro]
63 Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
64 Mapping between LPD and IPP Protocols (this document)
66 The document, 'Design Goals for an Internet Printing Protocol', takes a
67 broad look at distributed printing functionality, and it enumerates
68 real-life scenarios that help to clarify the features that need to be
69 included in a printing protocol for the Internet. It identifies
70 requirements for three types of users: end users, operators, and
71 administrators. It calls out a subset of end user requirements that are
72 satisfied in IPP/1.0. Operator and administrator requirements are out of
73 scope for version 1.0.
75 The document, 'Rationale for the Structure and Model and Protocol for
76 the Internet Printing Protocol', describes IPP from a high level view,
77 defines a roadmap for the various documents that form the suite of IPP
78 specifications, and gives background and rationale for the IETF working
79 group's major decisions.
81 The document, 'Internet Printing Protocol/1.0: Model and Semantics',
82 describes a simplified model with abstract objects, their attributes,
83 and their operations. It introduces a Printer and a Job object. The Job
84 object supports multiple documents per Job. It also addresses security,
85 internationalization, and directory issues.
87 The document, 'Internet Printing Protocol/1.0: Encoding and Transport',
88 is a formal mapping of the abstract operations and attributes defined in
89 the model document onto HTTP/1.1. It defines the encoding rules for a
90 new Internet media type called 'application/ipp'.
92 This document 'Internet Printing Protocol/1.0: Implementer's Guide',
93 gives advice to implementers of IPP clients and IPP objects.
95 Jacobs, Martin Expires May 16, 1999
96 TABLE OF CONTENTS
98 1. Introduction......................................................4
99 2. Terminology.......................................................4
100 3. Mapping from LPD Commands to IPP Operations.......................5
101 3.1 Print any waiting jobs..........................................5
102 3.2 Receive a printer job...........................................5
103 3.2.1 Abort job....................................................6
104 3.2.2 Receive control file.........................................7
105 3.2.3 Receive data file............................................7
106 3.3 Send queue state (short)........................................8
107 3.4 Send queue state (long).........................................9
108 3.5 Remove jobs....................................................11
109 4. Mapping of LPD Control File Lines to IPP Operation and Job Template
110 Attributes............................................................11
111 4.1 Required Job Functions.........................................12
112 4.2 Optional Job Functions.........................................13
113 4.3 Required Document Functions....................................13
114 4.4 Recommended Document Functions.................................14
115 5. Mapping from IPP operations to LPD commands......................14
116 5.1 Print-Job......................................................15
117 5.2 Print-URI......................................................16
118 5.3 Validate-Job...................................................16
119 5.4 Create-Job.....................................................16
120 5.5 Send-Document..................................................17
121 5.6 Send-URI.......................................................17
122 5.7 Cancel-Job.....................................................17
123 5.8 Get-Printer-Attributes.........................................17
124 5.9 Get-Job-Attributes.............................................18
125 5.10 Get-Jobs.....................................................19
126 6. Mapping of IPP Attributes to LPD Control File Lines..............19
127 6.1 Required Job Functions.........................................20
128 6.2 Optional Job Functions.........................................20
129 6.3 Required Document Functions....................................20
130 7. Security Considerations..........................................21
131 8. References.......................................................21
132 9. Author's Addresses...............................................23
133 10. Appendix A: ABNF Syntax for response of Send-queue-state (short).23
134 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)..24
135 12. Appendix C: Unsupported LPD functions............................24
136 13. Appendix D: Full Copyright Statement.............................25
138 Jacobs, Martin Expires May 16, 1999
139 Mapping between the LPD and IPP Protocols
141 1. Introduction
143 The reader of this specification is expected to be familiar with the IPP
144 Model and Semantics specification [ipp-mod], the IPP Encoding and
145 Transport [ipp-pro], and the Line Printer Daemon (LPD) protocol
146 specification [rfc1179] as described in RFC 1179.
148 RFC 1179 was written in 1990 in an attempt to document existing LPD
149 protocol implementations. Since then, a number of undocumented
150 extensions have been made by vendors to support functionality specific
151 to their printing solutions. All of these extensions consist of
152 additional control file commands. This document does not address any of
153 these vendor extensions. Rather it addresses existing practice within
154 the context of the features described by RFC 1179. Deviations of
155 existing practice from RFC 1179 are so indicated.
157 Other LPD control file commands in RFC 1179 are obsolete. They are
158 intended to work on "text" only formats and are inappropriate for many
159 contemporary document formats that completely specify each page. This
160 document does not address the support of these obsolete features.
162 In the area of document formats, also known as page description
163 languages (PDL), RFC 1179 defines a fixed set with no capability for
164 extension. Consequently, some new PDL's are not supported, and some of
165 those that are supported are sufficiently unimportant now that they have
166 not been registered for use with the Printer MIB[rfc1759] and IPP[ipp-
167 mod] [ipp-pro], though they could be registered if desired. See the
168 Printer MIB specification [rfc1759] and/or the IPP Model specification
169 [ipp-mod] for instructions for registration of document-formats with
170 IANA. IANA lists the registered document-formats as "printer
171 languages".
173 This document addresses the protocol mapping for both directions:
174 mapping of the LPD protocol to the IPP protocol and mapping of the IPP
175 protocol to the LPD protocol. The former is called the "LPD-to-IPP
176 mapper" and the latter is called the "IPP-to-LPD mapper".
178 This document is an informational document that is not on the standards
179 track. It is intended to help implementers of gateways between IPP and
180 LPD. It also provides an example, which gives additional insight into
181 IPP.
183 2. Terminology
185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
187 document are to be interpreted as described in RFC 2119 [rfc2119].
189 Jacobs, Martin Expires May 16, 1999
190 RFC 1179 uses the word "command" in two contexts: for over-the-wire
191 operations and for command file functions. This document SHALL use the
192 word "command" for the former and the phrase "functions" for the latter.
193 The syntax of the LPD commands is given using ABNF [rfc2234].
195 The following tokens are used in order to make the syntax more readable:
197 LF stands for %x0A (linefeed)
198 SP stands for %x20. (space)
199 DIGIT stands for %x30-39 ("0" to "9")
201 3. Mapping from LPD Commands to IPP Operations
203 This section describes the mapping from LPD commands to IPP operations.
204 Each of the following sub-sections appear as sub-sections of section 5
205 of RFC 1179.
207 The following table summarizes the IPP operation that the mapper uses
208 when it receives an LPD command. Each section below gives more detail:
210 LPD command IPP operation
212 print-any-waiting-jobs ignore
213 receive-a-printer-job Print-Job or Create-Job/Send-Document
214 send queue state (short Get-Printer-Attributes and Get-Jobs
215 or long)
216 remove-jobs Cancel-Job
218 3.1 Print any waiting jobs
220 Command syntax:
222 print-waiting-jobs = %x01 printer-name LF
224 This command causes the LPD daemon check its queue and print any waiting
225 jobs. An IPP printer handles waiting jobs without such a nudge.
227 If the mapper receives this LPD command, it SHALL ignore it and send no
228 IPP operation.
230 3.2 Receive a printer job
232 Command syntax:
234 receive-job = %x02 printer-name LF
236 The control file and data files mentioned in the following paragraphs
237 are received via LPD sub-commands that follow this command. Their
238 mapping to IPP commands and attributes is described later in this
239 section.
241 The mapper maps the 'Receive a printer job' command to either:
243 Jacobs, Martin Expires May 16, 1999
244 @ the Print-Job operation which includes a single data file or
245 @ the Create-Job operation followed by one Send-Document
246 operation for each data file.
248 If the IPP printer supports both Create-Job and Send-Document, and if a
249 job consists of:
251 @ a single data file, the mapper SHOULD use the Print-Job
252 operation, but MAY use the Create-Job and Send-Document
253 operations.
254 @ more than one data file, the mapper SHALL use Create-Job
255 followed by one Send-Document for each received LPD data file.
257 If the IPP printer does not support both Create-Job and Send-Document,
258 and if a job consists of:
260 @ a single data file, the mapper SHALL use the PrintJob
261 operation.
262 @ more than one data file, the mapper SHALL submit each received
263 LPD data file as a separate Print-Job operation (thereby
264 converting a single LPD job into multiple IPP jobs).
266 If the mapper uses Create-Job and Send-Document, it MUST send the
267 Create-Job operation before it sends any Send-Document operations
268 whether the LPD control file, which supplies attributes for Create-Job,
269 arrives before or after all LPD data files.
271 NOTE: This specification does not specify how the mapper maps: the LPD
272 Printer-name operand to the IPP "printer-uri" operation attribute.
274 The following three sub-sections gives further details about the mapping
275 from LPD receive-a-printer-job sub-commands. Each of the following sub-
276 sections appear as sub-sections of section 6 of RFC 1179.
278 3.2.1 Abort job
280 Sub-command syntax:
282 abort-job = %x1 LF
284 This sub-command of receive-a-printer-job is intended to abort any job
285 transfer in process.
287 If the mapper receives this sub-command, it SHALL cancel the job that it
288 is in the process of transmitting.
290 If the mapper is in the process of sending a Print-Job or Create-Job
291 operation, it terminates the job either by closing the connection, or
292 performing the Cancel-Job operation with the job-uri that it received
293 from the Print-Job or Create-Job operation.
295 Jacobs, Martin Expires May 16, 1999
296 NOTE: This sub-command is implied if at any time the connection between
297 the LPD client and server is terminated before an entire print job has
298 been transferred via an LPD Receive-a-printer-job request.
300 3.2.2 Receive control file
302 Sub-command syntax:
304 receive-control-file = %x2 number-of-bytes SP name-of-control-file LF
305 number-of-bytes = 1*DIGIT
306 name-of-control-file = "cfA" job-number client-host-name
307 ; e.g. "cfA123woden"
308 job-number = 3DIGIT
309 client-host-name =
311 This sub-command is roughly equivalent to the IPP Create-Job operation.
313 The mapper SHALL use the contents of the received LPD control file to
314 create IPP operation attribute and job template attribute values to
315 transmit with the Print-Job or Create-Job operation.
317 3.2.3 Receive data file
319 Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file
321 receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
322 number-of-bytes = 1*DIGIT
323 name-of-data-file = "df" letter job-number client-host-name
324 ; e.g. "dfA123woden for the first file
325 letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z"
326 ; first file is "A",
327 ; second "B", and 52nd file is "z"
328 job-number = 3DIGIT
329 client-host-name =
331 This sub-command is roughly equivalent to the IPP Send-Document
332 operation.
334 The mapper SHALL use the contents of the received LPD data file as the
335 data to transmit with the IPP Print-Job or Send-Document operation.
337 Although RFC-1179 alludes to a method for passing an unspecified
338 length data file by using an octet-count of zero, no implementations
339 support this feature. The mapper SHALL reject a job that has a value of
340 0 in the number-of-bytes field.
342 Jacobs, Martin Expires May 16, 1999
343 3.3 Send queue state (short)
345 Command syntax:
347 send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF
349 The mapper's response to this command includes information about the
350 printer and its jobs. RFC 1179 specifies neither the information nor the
351 format of its response. This document requires the mapper to follow
352 existing practice as specified in this document.
354 The mapper SHALL produce a response in the following format which
355 consists of a printer-status line optionally followed by a heading line,
356 and a list of jobs. This format is defined by examples below. Appendix A
357 contains the ABNF syntax.
359 For an printer with no jobs, the response starts in column 1 and is:
361 no entries
363 For a printer with jobs, an example of the response is:
365 killtree is ready and printing
366 Rank Owner Job Files Total Size
367 active fred 123 stuff 1204 bytes
368 1st smith 124 resume, foo 34576 bytes
369 2nd fred 125 more 99 bytes
370 3rd mary 126 mydoc 378 bytes
371 4th jones 127 statistics.ps 4567 bytes
372 5th fred 128 data.txt 9 bytes
374 The column numbers of above headings and job entries are:
376 | | | | |
377 01 08 19 35 63
379 The mapper SHALL produce each field above from the following IPP
380 attribute:
382 LPD field IPP attribute special conversion details
384 printer- printer-state and For a printer-state of idle or
385 status printer-state-reasons processing, the mapper SHALL use
386 the formats above. For stopped,
387 the mapper SHALL use printer-
388 state-reasons to produce an
389 unspecified format for the error.
390 rank number-of- the mapper SHALL the format above
391 intervening-jobs
392 owner job-originating-user- unspecified conversion; job-
393 name originating-user-name may be the
394 mapper's user-name
395 job job-id the mapper shall use the job-id
397 Jacobs, Martin Expires May 16, 1999
398 LPD field IPP attribute special conversion details
400 files document-name the mapper shall create a comma
401 separated list of the document-
402 names and then truncate this list
403 to the first 24 characters
404 total- job-k- the mapper shall multiple the
405 size octets*copies*1024 value of job-k-octets by 1024 and
406 by the value of the "copies"
407 attribute.
409 A mapper SHOULD use the job attribute number-of-intervening-jobs rather
410 than the job's position in a list of jobs to determine 'rank' because a
411 Printer may omit jobs that it wants to keep secret. If a printer doesn't
412 support the job attribute number-of-intervening-jobs, a mapper MAY use
413 the job's position.
415 Note: a Printer may set the value of job-originating-user-name to the
416 authenticated user or to the value of "requesting-user-name", depending
417 on the implementation and configuration. For a gateway, the
418 authenticated user is the user-id of the gateway, but the "requesting-
419 user-name" may contain the name of the user who is the gateway's client.
421 In order to obtain the information specified above, The LPD-to-IPP
422 mapper SHALL use the Get-Printer-Attributes operation to get printer-
423 status and SHOULD use the Get-Jobs operation to get information about
424 all of the jobs. If the LPD command contains job-numbers or user-names,
425 the mapper MAY handle the filtering of the response. If the LPD command
426 contains job-numbers but no user-names, the mapper MAY use Get-Job-
427 Attributes on each converted job-number rather than Get-Jobs. If the LPD
428 command contains a single user-name but no job-numbers, the mapper MAY
429 use Get-Jobs with the my-jobs option if the server supports this option
430 and if the server allows the client to be a proxy for the LPD user.
432 NOTE: This specification does not define how the mapper maps the LPD
433 Printer-name operand to the IPP "printer-uri" operation attribute.
435 3.4 Send queue state (long)
437 Command syntax:
439 send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
441 The mapper's response to this command includes information about the
442 printer and its jobs. RFC 1179 specifies neither the information nor the
443 format of its response. This document requires the mapper to follow
444 existing practice as specified in this document.
446 The mapper SHALL produce a response in the following format which
447 consists of a printer-status line optionally followed a list of jobs,
448 where each job consists of a blank line, a description line, and one
450 Jacobs, Martin Expires May 16, 1999
451 line for each file. The description line contains the user-name, rank,
452 job-number and host. This format is defined by examples below. Appendix
453 B contain the ABNF syntax.
455 For an printer with no jobs the response is:
457 no entries
459 For a printer with jobs, an example of the response is:
461 killtree is ready and printing
463 fred: active [job 123 tiger]
464 2 copies of stuff 602 bytes
466 smith: 1st [job 124 snail]
467 2 copies of resume 7088 bytes
468 2 copies of foo 10200 bytes
470 fred: 2nd [job 125 tiger]
471 more 99 bytes
473 The column numbers of above headings and job entries are:
475 | | |
476 01 09 41
478 Although the format of the long form is different from the format of the
479 short form, their fields are identical except for a) the copies and host
480 fields which are only in the long form, and b) the "size" field
481 contains the single copy size of each file. Thus the sum of the file
482 sizes in the "size" field times the value of the "copies" field
483 produces the value for the "Total Size" field in the short form. For
484 fields other than the host and copies fields, see the preceding section.
485 For the host field see the table below.
487 LPD field IPP attribute special conversion details
489 host unspecified conversion; job-
490 originating-host may be the
491 mapper's host
492 copies copies the mapper shall assume the
493 value of copies precedes the
494 string "copies of "; otherwise,
495 the value of copies is 1.
497 NOTE: This specification does not define how the mapper maps the LPD
498 Printer-name operand to the IPP printer-uri operation attribute.
500 Jacobs, Martin Expires May 16, 1999
501 3.5 Remove jobs
503 Command syntax:
505 remove-jobs = %x05 printer-name SP agent
506 *(SP(user-name / job-number)) LF
508 The agent operand is the user-name of the user initiating the remove-
509 jobs command. The special user-name 'root' indicates a privileged user
510 who can remove jobs whose user-name differs from the agent..
512 The mapper SHALL issue one Cancel-Job operation for each job referenced
513 by the remove-jobs command. Each job-number in the remove-jobs command
514 references a single job. Each user-name in the remove-jobs command
515 implicitly references all jobs owned by the specified user. The active
516 job is implicitly referenced when the remove-jobs command contains
517 neither job-numbers nor user-names. The mapper MAY use Get-Jobs to
518 determine the job-uri of implicitly referenced jobs.
520 The mapper SHALL not use the agent name of 'root' when end-users cancel
521 their own jobs. Violation of this rule creates a potential security
522 violation, and it may cause the printer to issue a notification that
523 misleads a user into thinking that some other person canceled the job.
525 If the agent of a remove-jobs command for a job J is the same as the
526 user name specified with the 'P' function in the control file for job J,
527 then the mapper SHALL ensure that the initiator of the Cancel-Job
528 command for job J is the same as job-originating-user for job J.
530 Note: This requirement means that a mapper must be consistent in who the
531 receiver perceives as the initiator of IPP operations. The mapper either
532 acts as itself or acts on behalf of another user. The latter is
533 preferable if it is possible. This consistency is necessary between
534 Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but
535 it is also desirable for other operations. For example, Get-Jobs may
536 give more information about job submitted by the initiator of this
537 operation.
539 NOTE: This specification does not define how the mapper maps: (1) the
540 LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to
541 the IPP "job-uri".
543 NOTE: This specification does not specify how the mapper maps the LPD
544 user-name to the IPP job-originating-user because the mapper may use its
545 own user-name with jobs.
547 4. Mapping of LPD Control File Lines to IPP Operation and Job Template
548 Attributes
550 This section describes the mapping from LPD control file lines (called
551 'functions') to IPP operation attributes and job template attributes.
552 The mapper receives the control file lines via the LPD receive-control-
554 Jacobs, Martin Expires May 16, 1999
555 file sub-command.. Each of the LPD functions appear as sub-sections of
556 section 7 of RFC 1179.
558 In LPD control file lines, the text operands have a maximum length of 31
559 or 99 while IPP operation attribute and job template attribute values
560 have a maximum of 255 or 1023 octets, depending on the attribute syntax.
561 Therefore, no data is lost.
563 The mapper converts each supported LPD function to its corresponding IPP
564 operation or job template attribute as defined by tables in the
565 subsections that follow. These subsections group functions according to
566 whether they are:
568 @ required with a job,
569 @ optional with a job
570 @ required with each document.
572 In the tables below, each LPD value is given a name, such as 'h'. If an
573 IPP value uses the LPD value, then the IPP value column contains the LPD
574 name, such as 'h' to denote this. Otherwise, the IPP value column
575 specifies the literal value.
577 4.1 Required Job Functions
579 The following LPD functions MUST be in a received LPD job. The mapper
580 SHALL receive each of the following LPD functions and SHALL include the
581 information as a operation or job template attribute with each IPP job.
582 The functions SHOULD be in the order 'H', 'P' and they SHOULD be the
583 first two functions in the control file, but they MAY be anywhere in the
584 control file and in any order:
586 LPD function IPP
587 name value description name value
589 H h Originating Host h (in security layer)
590 P u User identification requesting- u (and in security
591 user-name layer)
592 none ipp- 'true'
593 attribute-
594 fidelity
596 A mapper MAY sen. its own host rather than the client's host, and a
597 mapper MAY send its own user-name as user identification rather than the
598 client user. But in any case, the values sent SHALL be compatible with
599 the Cancel-Job operation. The IPP operation MAY have no way to specify
600 an originating host-name.
602 The mapper SHALL include ipp-attribute-fidelity = true so that it
603 doesn't have to determine which attributes a printer supports.
605 Jacobs, Martin Expires May 16, 1999
606 4.2 Optional Job Functions
608 The following LPD functions MAY be present in a received job. These
609 function SHOULD follow the required job functions and precede the
610 document functions, but they MAY be anywhere in the control file.
612 If the mapper receives such an LPD function, the mapper SHALL include
613 the corresponding IPP attribute with the value converted as specified in
614 the table below. If the mapper does not receive such an LPD attribute,
615 the mapper SHALL NOT include the corresponding IPP attribute, except the
616 'L' LPD function whose absence has a special meaning as noted in the
617 table.
619 LPD function IPP
620 name value description name value
622 J j Job name for job-name j
623 banner page
624 L l Print banner page job-sheets 'standard' if 'L' is
625 present
626 'none' if 'L' is present
627 M m Mail When Printed IPP has no notification
628 mechanism. To support
629 this LPD feature, the
630 gateway must poll using
631 the Get-Job-Attributes
632 operation.
633 .
635 4.3 Required Document Functions
637 The mapper SHALL receive one set of the required document functions with
638 each copy of a document, and SHALL include the converted information as
639 operation or job template attributes with each IPP document.
641 If the control file contains required and recommended document
642 functions, the required functions SHOULD precede the recommended ones
643 and if the job contains multiple documents, all the functions for each
644 document are grouped together as shown in the example of section 6.3
645 "Required Document Functions". However, the document functions MAY be in
646 any order.
648 LPD function IPP
649 name valu description name value
650 e
652 f fff Print formatted document-format 'application/octet-
653 file stream'
654 l fff Print file leaving document-format 'application/octet-
655 control characters stream'
657 Jacobs, Martin Expires May 16, 1999
659 LPD function (cont.) IPP
660 o fff Print Postscript document-format 'application/PostScri
661 output file pt'
662 copies see note
664 Note: In practice, the 'f' LPD function is often overloaded. It is often
665 used with any format of document data including PostScript and PCL data.
667 Note: In practice, the 'l' LPD function is often used as a rough
668 equivalent to the 'f' function.
670 Note: When RFC 1179 was written, no implementation supported the 'o'
671 function; instead 'f' was used for PostScript. Windows NT now sends 'o'
672 function for a PostScript file.
674 Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name of
675 the data file as transferred, e.g. "dfA123woden".
677 If the mapper receives any other lower case letter, the mapper SHALL
678 reject the job because the document contains a format that the mapper
679 does not support.
681 The mapper determines the number of copies by counting the number of
682 occurrences of each 'fff' file with one of the lower-case functions
683 above. For example, if 'f dfA123woden' occurs 4 times, then copies has a
684 value of 4. Although the LPD protocol allows the value of copies to be
685 different for each document, the commands and the receiving print
686 systems don't support this.
688 4.4 Recommended Document Functions
690 The mapper SHOULD receive one set of the recommended document functions
691 with each document, and SHOULD include the converted information as an
692 operation or job template attribute with each IPP document. The
693 functions SHOULD be received in the order 'U' and 'N', but they MAY
694 arrive in any order.
696 LPD function IPP
697 name value description name value
699 U fff ignored
700 N n Name of source file document-name n
702 Note: the value 'fff' of the 'U' function is the name of the data file
703 as transferred, e.g. "dfA123woden".
705 5. Mapping from IPP operations to LPD commands
707 If the IPP-to-LPD mapper receives an IPP operation, the following table
708 summarizes the LPD command that it uses. Each section below gives the
710 Jacobs, Martin Expires May 16, 1999
711 detail. Each of the following sub-sections appear as sub-sections of
712 section 3 in the document "Internet Printing Protocol/1.0: Model and
713 Semantics" [ipp-mod].
715 IPP operation LPD command
717 Print-Job or Print-URI or receive-a-printer-job
718 Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs
719 Validate-Job implemented by the mapper
720 Cancel-Job remove-jobs
721 Get-Printer-Attributes, Get-Job- send queue state (short or long)
722 Attributes or Get-Jobs
724 5.1 Print-Job
726 The mapper SHALL send the following commands in the order listed below:
728 @ receive-a-printer-job command
729 @ both receive-control-file sub-command and receive-data-file
730 sub-command
731 (unspecified order, see Note below)
732 @ print-any-waiting-jobs command,
733 except that if the mapper is sending a sequence of receive-a-
734 printer-job commands, it MAY omit sending print-any-waiting-
735 jobs after any receive-a printer-job command that is neither
736 the first nor last command in this sequence
738 Note: it is recommended that the order of the receive-control-file sub-
739 command and the receive-data-file sub-command be configurable because
740 either order fails for some print systems. Some print systems assume
741 that the control file follows all data files and start printing
742 immediately on receipt of the control file. When such a print system
743 tries to print a data file that has not arrived, it produces an error.
744 Other print systems assume that the control file arrives before the data
745 files and start printing when the first data file arrives. Such a system
746 ignores the control information, such as banner page or copies.
748 NOTE: This specification does not define the mapping between the IPP
749 printer-uri and the LPD printer-name.
751 The mapper SHALL send the IPP operation attributes and job template
752 attributes received from the operation to the LPD printer by using the
753 LPD receive-control-file sub-command. The mapper SHALL create the LPD
754 job-number for use in the control file name, but the receiving printer
755 MAY, in some circumstances, assign a different job-number to the job.
756 The mapper SHALL create the IPP job-id and IPP job-uri returned in the
757 Print-Job response.
759 NOTE: This specification does not specify how the mapper determines the
760 LPD job-number, the IPP job-id or the IPP job-uri of a job that it
761 creates nor does it specify the relationship between the IPP job-uri,
762 IPP the job-id and the LPD job-number, both of which the mapper creates.
763 However, it is likely that the mapper will use the same integer value
765 Jacobs, Martin Expires May 16, 1999
766 for both the LPD job-number and the IPP job-id, and that the IPP Job-uri
767 is the printer's URI with the job-id concatenated on the end.
769 The mapper SHALL send data received in the IPP operation to the LPD
770 printer by using the LPD receive-data-file sub-command. The mapper SHALL
771 specify the exact number of bytes being transmitted in the number-of-
772 bytes field of the receive-data-file sub-command. It SHALL NOT use a
773 value of 0 in this field.
775 If the mapper, while it is transmitting a receive-a-printer-job command
776 or sub-command, either detects that its IPP connection has closed or
777 receives a Cancel-Job operation, the mapper SHALL terminate the LPD job
778 either with the abort sub-command or the remove-jobs command.
780 This document does not address error code conversion.
782 5.2 Print-URI
784 The mapper SHALL handle this operation in the same way as a Print-Job
785 operation except that it SHALL obtain data referenced by the "document-
786 uri" operation attribute and SHALL then treat that data as if it had
787 been received via a Print-Job operation.
789 5.3 Validate-Job
791 The mapper SHALL perform this operation directly. Because LPD supports
792 very few attributes, this operation doesn't have much to check.
794 5.4 Create-Job
796 The mapper SHALL handle this operation like Print-Job, except:
798 @ the mapper SHALL send the control file after it has received
799 the last Send-Document or Send-URI operation because the
800 control file contains all the document-name and document-
801 format values specified in the Send-Document and Send-URI
802 operations.
803 @ the mapper SHALL perform one receive-data-file sub-command for
804 each Send-Document or Send-URI operation received and in the
805 same order received.
806 @ the mapper SHALL send the control file either before all data
807 files or after all data files.
808 (See the note in the section on Print-Job about the dilemma of
809 sending the control file either before or after the data
810 files.
812 Jacobs, Martin Expires May 16, 1999
814 5.5 Send-Document
816 The mapper performs a receive-data-file sub-command on the received
817 data. See the preceding section 5.4 "Create-Job" for the details.
819 5.6 Send-URI
821 The mapper SHALL obtain the data referenced by the "document-uri"
822 operation attribute, and SHALL then treat that data as if it had been
823 received via a Send-Document operation. See the preceding section 5.5
824 "Send-Document" for the details.
826 5.7 Cancel-Job
828 The mapper SHALL perform a remove-jobs command with the following
829 operation attributes:
831 @ the printer is the one to which the job was submitted, that is
832 the IPP printer-uri is mapped to an LPD printer-name by the
833 same mechanism as for all commands
834 @ the agent is the authenticated user-name of the IPP client
835 @ the job-number is the job-id returned by the Print-Job
836 command, that is, the LPD job-number has the same value as the
837 IPP job-id for likely implementations
839 5.8 Get-Printer-Attributes
841 LPD severely limits the set of attributes that the mapper is able to
842 return in its response for this operation. The mapper SHALL support, at
843 most, the following printer attributes:
845 @ printer-state
846 @ printer-state-reasons
848 The mapper uses either the long or short form of the "send queue state"
849 command.
851 The mapper SHALL assume that the LPD response that it receives has the
852 format and information specified in section 3.3 "
854 Jacobs, Martin Expires May 16, 1999
855 Send queue state (short)" and section 3.4 "Send queue state (long)".
856 The mapper SHALL determine the value of each requested attribute by
857 using the inverse of the mapping specified in the two aforementioned
858 sections.
860 Note: the mapper can determine the response from the printer-status line
861 without examining the rest of the LPD response.
863 5.9 Get-Job-Attributes
865 LPD severely limits the set of attributes that the mapper is able to
866 return in its response for this operation. The mapper SHALL support, at
867 most, the following job attributes:
869 @ number-of-intervening-jobs
870 @ job-originating-user-name
871 @ job-id
872 @ document-name
873 @ job-k-octets
874 @ copies
876 The mapper uses either the long or short form of the "send queue state"
877 command. If it receives a request for the "job-k-octets" or "copies"
878 and supports the attribute it SHALL use the long form; otherwise, it
879 SHALL use the short form.
881 Note: the value of job-k-octets is the value in the short form divided
882 by the number of "copies" which is on the long form only. Its value can
883 also be determined by adding the "size" field values for each document
884 in the job in the long form.
886 The mapper SHALL assume that the LPD response that it receives has the
887 format and information specified in section 3.3 "
889 Jacobs, Martin Expires May 16, 1999
890 Send queue state (short)" and section 3.4 "Send queue state (long)".
891 The mapper SHALL determine the value of each requested attribute by
892 using the inverse of the mapping specified in the two aforementioned
893 sections.
895 Note: when the mapper uses the LPD short form, it can determine the
896 response from the single LPD line that pertains to the job specified by
897 the Get-Job-Attributes operation.
899 Note: the mapper can use its correspondence between the IPP job-id, job-
900 uri and the LPD job-number.
902 5.10 Get-Jobs
904 The mapper SHALL perform this operation in the same way as Get-Job-
905 Attributes except that the mapper converts all the LPD job-lines, and
906 the IPP response contains one job object for each job-line in the LPD
907 response.
909 6. Mapping of IPP Attributes to LPD Control File Lines
911 This section describes the mapping from IPP operation attributes and job
912 template attributes to LPD control file lines (called 'functions'). The
913 mapper receives the IPP operation attributes and job template atributes
914 via the IPP operation. Each of the IPP operation attributes and job
915 template attributes appear as sub-sections of section 3 and 4.2 in the
916 IPP model document [ipp-mod].
918 In the context of LPD control file lines, the text operands have a
919 maximum length of 31 or 99 while IPP operation attributes and job
920 template attributes have a maximum of 255 or 1023 octets, depending on
921 the attribute syntax. Therefore, there may be some data loss if the IPP
922 operation attribute and job template attribute values exceed the maximum
923 length of the LPD equivalent operands.
925 The mapper converts each supported IPP operation attribute and job
926 template attribute to its corresponding LPD function as defined by
927 tables in the subsections that follow. These subsections group functions
928 according to whether they are:
930 @ required with a job,
931 @ optional with a job
932 @ required with each document.
934 In the tables below, each IPP value is given a name, such as 'h'. If an
935 LPD value uses the IPP value, then the LPD value column contains the IPP
936 name, such as 'h' to denote this. Otherwise, the LPD value column
937 specifies the literal value.
939 Jacobs, Martin Expires May 16, 1999
940 6.1 Required Job Functions
942 The mapper SHALL include the following LPD functions with each job, and
943 they SHALL have the specified value. They SHALL be the first functions
944 in the control file and they SHALL be in the order "H" and then "P".
946 IPP LPD function
947 name value name value description
949 (perhaps in security h H gateway host Originating Host
950 layer)
951 requesting-user-name u P u User identification
952 and in the security
953 layer
955 A mapper SHALL sends its own host rather than the client's host, because
956 some LPD systems require that it be the same as the host from which the
957 remove-jobs command comes. A mapper MAY send its own user name as user
958 identification rather than the client user. But in any case, the values
959 sent SHALL be compatible with the LPD remove-jobs operation.
961 6.2 Optional Job Functions
963 The mapper MAY include the following LPD functions with each job. They
964 SHALL have the specified value if they are sent. These functions, if
965 present, SHALL follow the require job functions, and they SHALL precede
966 the required document functions.
968 IPP attribute LPD function
969 name value nam value description
970 e
972 job-name j J j Job name for banner
973 page
974 job-sheets 'standard' L u Print banner page
975 job-sheets 'none' omit 'L' function
976 Note: 'L' has special meaning when it is omitted. If 'J' is omitted,
977 some undefined behavior occurs with respect to the banner page.
979 6.3 Required Document Functions
981 The mapper SHALL include one set of the following LPD functions with
982 each document, and they SHALL have the specified values. For each
983 document, the order of the functions SHALL be 'f', 'U' and then 'N',
984 where 'f' is replicated once for each copy.
986 IPP attribute LPD function
988 Jacobs, Martin Expires May 16, 1999
989 name value name value description
991 document- 'application/octet- f fff Print formatted file
992 format stream' or
993 'application/PostScrip
994 t'
995 copies c replicate 'f' 'c'
996 times
997 none U fff Unlink data file
998 document- n N n Name of source file
999 name
1001 Note: the value 'fff' of the 'f' and 'U' functions is the name of the
1002 data file as transferred, e.g. "dfA123woden".
1004 Note: the mapper SHALL not send the 'o' function
1006 ISSUE: should we register DVI, troff or ditroff?
1008 If the mapper receives no "ipp-attribute-fidelitybest-effort" or it has
1009 a value of false, then the mapper SHALL reject the job if it specifies
1010 attributes or attribute values that are not among those supported in the
1011 above tables.
1013 Below is an example of the minimal control file for a job with three
1014 copies of two files 'foo' and 'bar':
1016 H tiger
1017 P jones
1018 f dfA123woden
1019 f dfA123woden
1020 f dfA123woden
1021 U dfA123woden
1022 N foo
1023 f dfB123woden
1024 f dfB123woden
1025 f dfB123woden
1026 U dfB123woden
1027 N bar
1029 7. Security Considerations
1031 There are no security issues beyond those covered in the IPP Encoding
1032 and Transport document [ipp-pro], the IPP model document [ipp-mod] and
1033 the LPD document [rfc1179].
1035 8. References
1037 [ipp-iig] Hasting, Tom, et al., "Internet Printing Protocol/1.0:
1038 Implementer's Guide", draft-ietf-ipp-implementers-guide-00.txt,
1039 November 1998
1041 Jacobs, Martin Expires May 16, 1999
1043 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
1044 "Internet Printing Protocol/1.0: Model and Semantics", , November, 1998.
1047 [ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
1048 Printing Protocol/1.0: Encoding and Transport", draft-ietf-ipp-
1049 pro-07.txt, November 1998.
1051 [ipp-rat] Zilles, S., "Rationale for the Structure and Model and
1052 Protocol for the Internet Printing Protocol", draft-ietf-ipp-
1053 rat-04.txt, November 1998.
1055 [ipp-req] Wright, D., "Design Goals for an Internet Printing
1056 Protocol", draft-ietf-ipp-req-03.txt, November, 1998.
1058 [rfc1179] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179,
1059 August 1990.
1061 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and
1062 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
1064 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate
1065 Requirement Levels", RFC 2119, March 1997
1067 [rec2234] D. Crocker et al., "Augmented BNF for Syntax Specifications:
1068 ABNF", RFC 2234, November 1997.
1070 Jacobs, Martin Expires May 16, 1999
1072 9. Author's Addresses
1074 Robert Herriot (editor) Norm Jacobs
1075 Sun Microsystems Inc. Sun Microsystems Inc.
1076 901 San Antonio.Road., MPK-17 1430 Owl Ridge Rd.
1077 Mountain View, CA 94043 Colorado Springs, CO 80919
1079 Phone: 650-786-8995 Phone: 719-532-9927
1080 Fax: 650-786-7077 Fax: 719-535-0956
1081 Email: robert.herriot@eng.sun.com Email:
1082 Norm.Jacobs@Central.sun.com
1084 Thomas N. Hastings Jay Martin
1085 Xerox Corporation Underscore, Inc.
1086 701 S. Aviation Blvd., ESAE-231 41-C Sagamore Park Road
1087 El Segundo, CA 90245 Hudson, NH 03051-4915
1089 Phone: 310-333-6413 Phone: 603-889-7000
1090 Fax: 310-333-5514 Fax: 603-889-2699
1091 EMail: hastings@cp10.es.xerox.com Email: jkm@underscore.com
1093 10. Appendix A: ABNF Syntax for response of Send-queue-state (short)
1095 The syntax in ABNF for the response to the LPD command 'send-queue-state
1096 (long)' is:
1098 status-response = empty-queue / nonempty-queue
1099 empty-queue = "no-entries" LF
1100 nonempty-queue = printer-status LF heading LF *(job LF)
1101 printer-status = OK-status / error-status
1102 OK-status = printer-name SP "ready and printing" LF
1103 error-status = < implementation dependent status information >
1104 heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files"
1105 23SP "Total Size" LF
1106 ; the column headings and their values below begin
1107 at the columns
1108 ; 1, 8, 19, 35 and 63
1109 job = rank *SP owner *SP job *SP files *SP total-size "bytes"
1110 ; jobs are in order of oldest to newest
1111 rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1112 ; job that is printing is "active"
1113 ; other values show position in the queue
1114 owner =
1115 job = 1*3DIGIT ; job-number
1116 files = *( "," ) ; truncated to 24 characters
1117 total-size = 1*DIGIT ; combined size in bytes of all documents
1119 Jacobs, Martin Expires May 16, 1999
1121 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)
1123 The syntax in ABNF for the response to the LPD command 'send-queue-state
1124 (long)' is:
1126 status-response = empty-queue / nonempty-queue
1127 empty-queue = "no-entries" LF
1128 nonempty-queue = printer-status LF *job
1129 printer-status = OK-status / error-status
1130 OK-status = printer-name SP "ready and printing" LF
1131 error-status = < implementation dependent status information >
1132 job = LF line-1 LF line-2 LF
1133 line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
1134 line-2 = file-name 1*SP document-size "bytes"
1135 ; jobs are in order of oldest to newest
1136 rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1137 ; job that is printing is "active"
1138 ; other values show position in the queue
1139 owner =
1140 job = 1*3DIGIT
1141 file-name = [ 1*DIGIT "copies of" SP ]
1142 ; truncated to 24 characters
1143 document-size = 1*DIGIT ;size of single copy of the document.
1145 12. Appendix C: Unsupported LPD functions
1147 The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper
1148 ignores them and the IPP-to-LPD mapper does not send them.
1150 LPD command
1151 name description
1153 C Class for banner page
1154 I Indent Printing
1155 H Host of client
1156 M Mail when printed
1157 S Symbolic link data
1158 T Title for pr
1159 W Width of output
1160 1 troff R font
1161 2 troff I font
1162 3 troff B font
1163 4 troff S font
1165 The follow LPD functions specify document-formats which have no IPP
1166 equivalent, unless someone registers them. The LPD-to-IPP mapper rejects
1167 jobs that request such a document format, and the IPP-to-LPD mapper does
1168 not send them.
1170 Jacobs, Martin Expires May 16, 1999
1171 LPD command
1172 name description
1174 c Plot CIF file
1175 d Print DVI file
1176 g Plot file
1177 k reserved for Kerberized clients and servers
1178 n Print ditroff output file
1179 p Print file with 'pr' format
1180 r File to print with FORTRAN carriage control
1181 t Print troff output file
1182 v Print raster file
1183 z reserved for future use with the Palladium
1184 print system
1186 13. Appendix D: Full Copyright Statement
1188 Copyright (C)The Internet Society (1997). All Rights Reserved
1190 This document and translations of it may be copied and furnished to
1191 others, and derivative works that comment on or otherwise explain it or
1192 assist in its implementation may be prepared, copied, published and
1193 distributed, in whole or in part, without restriction of any kind,
1194 provided that the above copyright notice and this paragraph are included
1195 on all such copies and derivative works. However, this document itself
1196 may not be modified in any way, such as by removing the copyright notice
1197 or references to the Internet Society or other Internet organizations,
1198 except as needed for the purpose of developing Internet standards in
1199 which case the procedures for copyrights defined in the Internet
1200 Standards process must be followed, or as required to translate it into
1201 languages other than English.
1203 The limited permissions granted above are perpetual and will not be
1204 revoked by the Internet Society or its successors or assigns.
1206 This document and the information contained herein is provided on an "AS
1207 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
1208 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
1209 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
1210 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
1211 FITNESS FOR A PARTICULAR PURPOSE.
1213 Jacobs, Martin Expires May 16, 1999