idnits 2.17.1
draft-ietf-ipp-lpd-ipp-map-03.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.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 23
longer pages, the longest (page 1) being 60 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.
** There are 2 instances of too long lines in the document, the longest one
being 37 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 160 has weird spacing: '...ommands to IP...'
== Line 184 has weird spacing: '...If the mapper...'
== Line 201 has weird spacing: '...ate-Job opera...'
== Line 207 has weird spacing: '... single data ...'
== Line 208 has weird spacing: '...AY use the ...'
== (39 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 (December 19, 1997) is 9624 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-03.txt Tom Hastings
5 Xerox Corporation
6 Norm Jacobs
7 Sun Microsystems, Inc.
8 Jay Martin
9 Underscore, Inc.
10 December 19, 1997
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), ds.internic.net (US East Coast), or
30 ftp.isi.edu (US West Coast).
32 Copyright Notice
34 Copyright (C)The Internet Society (1997). All Rights Reserved.
36 Abstract
38 This Internet-Draft specifies the mapping between (1) the commands and
39 operands of the ''Line Printer Daemon (LPD) Protocol'' specified in RFC
40 1179 and (2) the operations and parameters of the Internet Printing
41 Protocol (IPP). One of the purposes of this document is to compare the
42 functionality of the two protocols. Another purpose is to facilitate
43 implementation of gateways between LPD and IPP.
45 This document is an informational document that is not on the standards
46 track. It is intended to help implementors of gateways between IPP and
47 LPD. It also provides an example, which gives additional insight into
48 IPP.
50 WARNING: RFC 1179 was not on standards track. While RFC 1179 was
51 intended to record existing practice, it fell short in some areas.
52 However, this specification maps between (1) the actual current practice
53 of RFC 1179 and (2) IPP. This document does not attempt to map the
54 numerous divergent extensions to the LPD protocol that have been made by
55 many implementers.
57 TABLE OF CONTENTS
59 1. Introduction........................................................3
60 2. Terminology.........................................................3
61 3. Mapping from LPD Commands to IPP Operations.........................4
62 3.1 Print any waiting jobs ...........................................4
63 3.2 Receive a printer job ............................................4
64 3.2.1 Abort job ....................................................5
65 3.2.2 Receive control file .........................................5
66 3.2.3 Receive data file ............................................5
67 3.3 Send queue state (short) .........................................6
68 3.4 Send queue state (long) ..........................................7
69 3.5 Remove jobs ......................................................8
70 4. Mapping of LPD Control File Lines to IPP Parameters.................9
71 4.1 Required Job Functions ...........................................9
72 4.2 Optional Job Functions ..........................................10
73 4.3 Required Document Functions .....................................10
74 4.4 Recommended Document Functions ..................................11
75 5. Mapping from IPP operations to LPD commands........................11
76 5.1 Print-Job .......................................................11
77 5.2 Print-URI .......................................................12
78 5.3 Validate-Job ....................................................12
79 5.4 Create-Job ......................................................12
80 5.5 Send-Document ...................................................13
81 5.6 Send-URI ........................................................13
82 5.7 Cancel-Job ......................................................13
83 5.8 Get-Printer-Attributes ..........................................13
84 5.9 Get-Job-Attributes ..............................................13
85 5.10 Get-Jobs .......................................................14
86 6. Mapping of IPP Parameters to LPD Control File Lines................14
87 6.1 Required Job Functions ..........................................15
88 6.2 Optional Job Functions ..........................................15
89 6.3 Required Document Functions .....................................15
90 7. Security...........................................................16
91 8. References.........................................................16
92 9. Author's Addresses.................................................16
93 10. Appendix A: ABNF Syntax for response of Send-queue-state (short)..17
94 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)...17
95 12. Appendix C: Unsupported LPD functions.............................18
96 13. Appendix D: Full Copyright Statement..............................18
97 Mapping between the LPD and IPP Protocols
99 1. Introduction
101 The reader of this specification is expected to be familiar with the IPP
102 Model and Semantics specification [ipp-mod], the IPP Protocol
103 specification [ipp-pro], and the Line Printer Daemon (LPD) protocol
104 specification [rfc1179] as described in RFC 1179.
106 RFC 1179 was written in 1990 in an attempt to document existing LPD
107 protocol implementations. Since then, a number of undocumented
108 extensions have been made by vendors to support functionality specific
109 to their printing solutions. All of these extensions consist of
110 additional control file commands. This document does not address any of
111 these vendor extensions. Rather it addresses existing practice within
112 the context of the features described by RFC 1179. Deviations of
113 existing practice from RFC 1179 are so indicated.
115 Other LPD control file commands in RFC 1179 are obsolete. They are
116 intended to work on "text" only formats and are inappropriate for many
117 contemporary document formats that completely specify each page. This
118 document does not address the support of these obsolete features.
120 In the area of document formats, also known as page description
121 languages (PDL), RFC 1179 defines a fixed set with no capability for
122 extension. Consequently, some new PDL's are not supported, and some of
123 those that are supported are sufficiently unimportant now that they have
124 not been registered for use with the Printer MIB[rfc1759] and IPP[ipp-
125 mod] [ipp-pro], though they could be registered if desired. See the
126 Printer MIB specification [rfc1759] and/or the IPP Model specification
127 [ipp-mod] for instructions for registration of document-formats with
128 IANA. IANA lists the registered document-formats as "printer
129 languages".
131 This document addresses the protocol mapping for both directions:
132 mapping of the LPD protocol to the IPP protocol and mapping of the IPP
133 protocol to the LPD protocol. The former is called the "LPD-to-IPP
134 mapper" and the latter is called the "IPP-to-LPD mapper".
136 This document is an informational document that is not on the standards
137 track. It is intended to help implementors of gateways between IPP and
138 LPD. It also provides an example, which gives additional insight into
139 IPP.
141 2. Terminology
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145 document are to be interpreted as described in RFC 2119 [abnf].
147 RFC 1179 uses the word "command" in two contexts: for over-the-wire
148 operations and for command file functions. This document SHALL use the
149 word "command" for the former and the phrase "functions" for the latter.
150 The syntax of the LPD commands is given using ABNF [abnf].
152 The following tokens are used in order to make the syntax more readable:
154 LF stands for %x0A (linefeed)
155 SP stands for %x20. (space)
156 DIGIT stands for %x30-39 ("0" to "9")
158 3. Mapping from LPD Commands to IPP Operations
160 This section describes the mapping from LPD commands to IPP operations.
161 Each of the following sub-sections appear as sub-sections of section 5
162 of RFC 1179.
164 The following table summarizes the IPP operation that the mapper uses
165 when it receives an LPD command. Each section below gives more detail.
167 LPD command IPP operation
169 print-any-waiting-jobs ignore
170 receive-a-printer-job Print-Job or Create-Job/Send-Document
171 send queue state (short Get-Printer-Attributesand Get-Jobs
172 or long)
173 remove-jobs Cancel-Job
175 3.1 Print any waiting jobs
177 Command syntax:
179 print-waiting-jobs = %x01 printer-name LF
181 This command causes the LPD daemon check its queue and print any waiting
182 jobs. An IPP printer handles waiting jobs without such a nudge.
184 If the mapper receives this LPD command, it SHALL ignore it and send no
185 IPP operation.
187 3.2 Receive a printer job
189 Command syntax:
191 receive-job = %x02 printer-name LF
193 The control file and data files mentioned in the following paragraphs
194 are received via LPD sub-commands that follow this command. Their
195 mapping to IPP commands and attributes is described later in this
196 section.
198 The mapper maps the 'Receive a printer job' command to either:
200 . the Print-Job operation which includes a single data file or
201 . the Create-Job operation followed by one Send-Document
202 operation for each data file.
204 If the IPP printer supports both Create-Job and Send-Document, and if a
205 job consists of:
207 . a single data file, the mapper SHOULD use the Print-Job
208 operation, but MAY use the Create-Job and Send-Document
209 operations.
210 . more than one data file, the mapper SHALL use Create-Job
211 followed by one Send-Document for each received LPD data file.
213 If the IPP printer does not support both Create-Job and Send-Document,
214 and if a job consists of:
216 . a single data file, the mapper SHALL use the PrintJob
217 operation.
218 . more than one data file, the mapper SHALL submit each received
219 LPD data file as a separate Print-Job operation (thereby
220 converting a single LPD job into multiple IPP jobs).
222 If the mapper uses Create-Job and Send-Document, it MUST send the
223 Create-Job operation before it sends any Send-Document operations
224 whether the LPD control file, which supplies attributes for Create-Job,
225 arrives before or after all LPD data files.
227 NOTE: This specification does not specify how the mapper maps: the LPD
228 Printer-name operand to the IPP "printer-uri" parameter.
230 The following 3 sub-sections gives further details about the mapping
231 from LPD receive-a-printer-job sub-commands. Each of the following
232 sub-sections appear as sub-sections of section 6 of RFC 1179.
234 3.2.1 Abort job
236 Sub-command syntax:
238 abort-job = %x1 LF
240 This sub-command of receive-a-printer-job is intended to abort any job
241 transfer in process.
243 If the mapper receives this sub-command, it SHALL cancel the job that it
244 is in the process of transmitting.
246 If the mapper is in the process of sending a Print-Job or Create-Job
247 operation, it terminates the job either by closing the connection, or
248 performing the Cancel-Job operation with the job-uri that it received
249 from the Print-Job or Create-Job operation.
251 NOTE: This sub-command is implied if at any time the connection between
252 the LPD client and server is terminated before an entire print job has
253 been transferred via an LPD Receive-a-printer-job request.
255 3.2.2 Receive control file
257 Sub-command syntax:
259 receive-control-file = %x2 number-of-bytes SP name-of-control-file LF
260 number-of-bytes = 1*DIGIT
261 name-of-control-file = "cfA" job-number client-host-name
262 ; e.g. "cfA123woden"
263 job-number = 3DIGIT
264 client-host-name =
266 This sub-command is roughly equivalent to the IPP Create-Job operation.
268 The mapper SHALL use the contents of the received LPD control file to
269 create IPP parameter and attribute values to transmit with the Print-Job
270 or Create-Job operation.
272 3.2.3 Receive data file
274 Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file
276 receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
277 number-of-bytes = 1*DIGIT
278 name-of-data-file = "df" letter job-number client-host-name
279 ; e.g. "dfA123woden for the first file
280 letter = %x41-5A / %x61-7A ; "A" " to Z", "a" to "z"
281 ; first file is "A",
282 ; second "B", and 52nd file is "z"
283 job-number = 3DIGIT
284 client-host-name =
286 This sub-command is roughly equivalent to the IPP Send-Document
287 operation.
289 The mapper SHALL use the contents of the received LPD data file as the
290 data to transmit with the IPP Print-Job or Send-Document operation.
292 Although RFC-1179 alludes to a method for passing an unspecified
293 length data file by using an octet-count of zero, no implementations
294 support this feature.. The mapper SHALL reject a job that has a value of
295 0 in the number-of-bytes field.
297 3.3 Send queue state (short)
299 Command syntax:
301 send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF
303 The mapper's response to this command includes information about the
304 printer and its jobs. RFC 1179 specifies neither the information nor the
305 format of its response. This document requires the mapper to follow
306 existing practice as specified in this document.
308 The mapper SHALL produce a response in the following format which
309 consists of a printer-status line optionally followed by a heading line,
310 and a list of jobs. This format is defined by examples below. Appendix A
311 contains the ABNF syntax.
313 For an printer with no jobs, the response starts in column 1 and is:
315 no entries
317 For a printer with jobs, an example of the response is:
319 killtree is ready and printing
320 Rank Owner Job Files Total Size
321 active fred 123 stuff 1204 bytes
322 1st smith 124 resume, foo 34576 bytes
323 2nd fred 125 more 99 bytes
324 3rd mary 126 mydoc 378 bytes
325 4th jones 127 statistics.ps 4567 bytes
326 5th fred 128 data.txt 9 bytes
328 The column numbers of above headings and job entries are:
330 | | | | |
331 01 08 19 35 63
333 The mapper SHALL produce each field above from the following IPP
334 attribute:
336 LPD field IPP attribute special conversion details
338 printer- printer-state and For a printer-state of idle or
339 status printer-state-reasons processing, the mapper SHALL use
340 the formats above. For stopped,
341 the mapper SHALL use printer-
342 state-reasons to produce an
343 unspecified format for the error.
344 rank number-of- the mapper SHALL the format above
345 intervening-jobs
346 owner job-originating-user- unspecified conversion; job-
347 name originating-user-name may be the
348 mapper's user-name
349 job job-id the mapper shall use the job-id
350 files document-name the mapper shall create a comma
351 separated list of the document-
352 names and then truncate this list
353 to the first 24 characters
354 total- job-k- the mapper shall multiple the
355 size octets*copies*1024 value of job-k-octets by 1024 and
356 by the value of the "copies"
357 attribute.
359 A mapper SHOULD use the job attribute number-of-intervening-jobs rather
360 than the job's position in a list of jobs to determine `rank' because a
361 Printer may omit jobs that it wants to keep secret. If a printer doesn't
362 support the job attribute number-of-intervening-jobs, a mapper MAY use
363 the job's position.
365 Note: a Printer may set the value of job-originating-user-name to the
366 authenticated user or to the value of "requesting-user-name", depending
367 on the implementation and configuration. For a gateway, the
368 authenticated user is the user-id of the gateway, but the "requesting-
369 user-name" may contain the name of the user who is the gateway's client.
371 In order to obtain the information specified above, The LPD-to-IPP
372 mapper SHALL use the Get-Printer-Attributes operation to get printer-
373 status and SHOULD use the Get-Jobs operation to get information about
374 all of the jobs. If the LPD command contains job-numbers or user-names,
375 the mapper MAY handle the filtering of the response. If the LPD command
376 contains job-numbers but no user-names, the mapper MAY use Get-Job-
377 Attributes on each converted job-number rather than Get-Jobs. If the LPD
378 command contains a single user-name but no job-numbers, the mapper MAY
379 use Get-Jobs with the my-jobs option if the server supports this option
380 and if the server allows the client to be a proxy for the LPD user.
382 NOTE: This specification does not define how the mapper maps the LPD
383 Printer-name operand to the IPP "printer-uri" parameter.
385 3.4 Send queue state (long)
387 Command syntax:
389 send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
391 The mapper's response to this command includes information about the
392 printer and its jobs. RFC 1179 specifies neither the information nor the
393 format of its response. This document requires the mapper to follow
394 existing practice as specified in this document.
396 The mapper SHALL produce a response in the following format which
397 consists of a printer-status line optionally followed a list of jobs,
398 where each job consists of a blank line, a description line, and one
399 line for each file. The description line contains the user-name, rank,
400 job-number and host. This format is defined by examples below. Appendix
401 B contain the ABNF syntax.
403 For an printer with no jobs the response is:
405 no entries
407 For a printer with jobs, an example of the response is:
409 killtree is ready and printing
411 fred: active [job 123 tiger]
412 2 copies of stuff 602 bytes
414 smith: 1st [job 124 snail]
415 2 copies of resume 7088 bytes
416 2 copies of foo 10200 bytes
418 fred: 2nd [job 125 tiger]
419 more 99 bytes
421 The column numbers of above headings and job entries are:
423 | | |
424 01 09 41
426 Although the format of the long form is different from the format of the
427 short form, their fields are identical except for a) the copies and host
428 fields which are only in the long form, and b) the "size" field
429 contains the single copy size of each file. Thus the sum of the file
430 sizes in the "size" field times the value of the "copies" field
431 produces the value for the "Total Size" field in the short form. For
432 fields other than the host and copies fields, see the preceding section.
433 For the host field see the table below.
435 LPD field IPP attribute special conversion details
437 host unspecified conversion; job-
438 originating-host may be the
439 mapper's host
440 copies copies the mapper shall assume the
441 value of copies precedes the
442 string "copies of "; otherwise,
443 the value of copies is 1.
445 NOTE: This specification does not define how the mapper maps the LPD
446 Printer-name operand to the IPP printer-uri parameter.
448 3.5 Remove jobs
450 Command syntax:
452 remove-jobs = %x05 printer-name SP agent
453 *(SP(user-name / job-number)) LF
455 The agent operand is the user-name of the user initiating the remove-
456 jobs command. The special user-name 'root' indicates a privileged user
457 who can remove jobs whose user-name differs from the agent..
459 The mapper SHALL issue one Cancel-Job operation for each job referenced
460 by the remove-jobs command. Each job-number in the remove-jobs command
461 references a single job. Each user-name in the remove-jobs command
462 implicitly references all jobs owned by the specified user. The active
463 job is implicitly referenced when the remove-jobs command contains
464 neither job-numbers nor user-names. The mapper MAY use Get-Jobs to
465 determine the job-uri of implicitly referenced jobs.
467 The mapper SHALL not use the agent name of `root' when end-users cancel
468 their own jobs. Violation of this rule creates a potential security
469 violation, and it may cause the printer to issue a notification that
470 misleads a user into thinking that some other person canceled the job.
472 If the agent of a remove-jobs command for a job J is the same as the
473 user name specified with the `P' function in the control file for job J,
474 then the mapper SHALL ensure that the caller of the Cancel-Job command
475 for job J is the same as job-originating-user for job J.
477 Note: This requirement means that a mapper must be consistent in who the
478 receiver perceives as the caller of IPP operations. The mapper either
479 acts as itself or acts on behalf of another user. The latter is
480 preferable if it is possible. This consistency is necessary between
481 Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but
482 it is also desirable for other operations. For example, Get-Jobs may
483 give more information about job submitted by the caller of this
484 operation.
486 NOTE: This specification does not define how the mapper maps: (1) the
487 LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to
488 the IPP "job-uri".
490 NOTE: This specification does not specify how the mapper maps the LPD
491 user-name to the IPP job-originating-user because the mapper may use its
492 own user-name with jobs.
494 4. Mapping of LPD Control File Lines to IPP Parameters
496 This section describes the mapping from LPD control file lines (called
497 `functions') to IPP operation input parameters. The mapper receives the
498 control file lines via the LPD receive-control-file sub-command.. Each
499 of the LPD functions appear as sub-sections of section 7 of RFC 1179.
501 In LPD control file lines, the text operands have a maximum length of 31
502 or 99 while IPP input parameters have a maximum of 255 characters.
503 Therefore, no data is lost.
505 The mapper converts each supported LPD function to its corresponding IPP
506 parameter as defined by tables in the subsections that follow. These
507 subsections group functions according to whether they are:
509 . required with a job,
510 . optional with a job
511 . required with each document.
513 In the tables below, each LPD value is given a name, such as `h'. If an
514 IPP value uses the LPD value, then the IPP value column contains the LPD
515 name, such as `h' to denote this. Otherwise, the IPP value column
516 specifies the literal value.
518 4.1 Required Job Functions
520 The following LPD functions MUST be in a received LPD job. The mapper
521 SHALL receive each of the following LPD functions and SHALL include the
522 information as a parameter with each IPP job. The functions SHOULD be in
523 the order `H', `P' and they SHOULD be the first two functions in the
524 control file, but they MAY be anywhere in the control file and in any
525 order.
527 LPD function IPP
528 name value description name value
530 H h Originating Host h (in security layer)
531 P u User identification requesting- u (and in security
532 user-name layer)
533 none ipp- `true'
534 attribute-
535 fidelity
537 A mapper MAY sends its own host rather than the client's host, and a
538 mapper MAY send its own user-name as user identification rather than the
539 client user. But in any case, the values sent SHALL be compatible with
540 the Cancel-Job operation. The IPP operation MAY have no way to specify
541 an originating host-name.
543 The mapper SHALL include ipp-attribute-fidelity =true so that it doesn't
544 have to determine which attributes a printer supports.
546 4.2 Optional Job Functions
548 The following LPD functions MAY be in a received job. These function
549 SHOULD follow the required job functions and precede the document
550 functions, but they MAY be anywhere in the control file.
552 If the mapper receives such an LPD function, the mapper SHALL include
553 the corresponding IPP attribute with the value converted as specified in
554 the table below. If the mapper does not receive such an LPD attribute,
555 the mapper SHALL NOT include the corresponding IPP attribute, except the
556 `L' LPD function whose absence has a special meaning as noted in the
557 table.
559 LPD function IPP
560 name value description name value
562 J j Job name for job-name j
563 banner page
564 L l Print banner page job-sheets `standard' if `L' is
565 present
566 `none' if `L' is present
567 M m Mail When Printed IPP has no notification
568 mechanism. To support
569 this LPD feature, the
570 gateway must poll
572 .
574 4.3 Required Document Functions
576 The mapper SHALL receive one set of the required document functions with
577 each copy of a document, and SHALL include the converted information as
578 parameters with each IPP document
580 If the control file contains required and recommended document
581 functions, the required functions SHOULD precede the recommended ones
582 and if the job contains multiple documents, all the functions for each
583 document are grouped together as shown in the example of section 6.3
584 "Required Document Functions". However, the document functions MAY be in
585 any order.
587 LPD function IPP
588 name valu description name value
589 e
591 f fff Print formatted document-format 'application/octet-
592 file stream'
593 l fff Print file leaving document-format 'application/octet-
594 control characters stream'
595 o fff Print Postscript document-format 'application/PostScri
596 output file pt'
597 copies see note
598 Note: In practice, the `f' LPD function is often overloaded. It is often
599 used with any format of document data including PostScript and PCL data.
601 Note: In practice, the `l' LPD function is often used as a rough
602 equivalent to the `f' function.
604 Note: When RFC 1179 was written, no implementation supported the `o'
605 function; instead `f' was used for PostScript. Windows NT now sends `o'
606 function for a PostScript file.
608 Note: the value `fff' of the `f', `l' and `o' functions is the name of
609 the data file as transferred, e.g. "dfA123woden".
611 If the mapper receives any other lower case letter, the mapper SHALL
612 reject the job because the document contains a format that the mapper
613 does not support.
615 The mapper determines the number of copies by counting the number of
616 occurrences of each `fff' file with one of the lower-case functions
617 above. For example, if `f dfA123woden' occurs 4 times, then copies has a
618 value of 4. Although the LPD protocol allows the value of copies to be
619 different for each document, the commands and the receiving print
620 systems don't support this.
622 4.4 Recommended Document Functions
624 The mapper SHOULD receive one set of the recommended document functions
625 with each document, and SHOULD include the converted information as
626 parameters with each IPP document. The functions SHOULD be received in
627 the order `U' and `N', but they MAY arrive in any order.
629 LPD function IPP
630 name value description name value
632 U fff ignored
633 N n Name of source file document-name n
635 Note: the value `fff' of the `U' function is the name of the data file
636 as transferred, e.g. "dfA123woden".
638 5. Mapping from IPP operations to LPD commands
640 If the IPP-to-LPD mapper receives an IPP operation, the following table
641 summarizes the LPD command that it uses. Each section below gives the
642 detail. Each of the following sub-sections appear as sub-sections of
643 section 3 in the document "Internet Printing Protocol/1.0: Model and
644 Semantics" [ipp-mod].
646 IPP operation LPD command
648 Print-Job or Print-URI or receive-a-printer-job
649 Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs
650 Validate-Job implemented by the mapper
651 Cancel-Job remove-jobs
652 Get-Printer-Attributes, Get-Job- send queue state (short or long)
653 Attributes or Get-Jobs
655 5.1 Print-Job
657 The mapper SHALL send the following commands in the order listed below:
659 . receive-a-printer-job command
660 . both receive-control-file sub-command and receive-data-file
661 sub-command
662 (unspecified order, see Note below)
663 . print-any-waiting-jobs command,
664 except that if the mapper is sending a sequence of receive-a-
665 printer-job commands, it MAY omit sending print-any-waiting-
666 jobs after any receive-a printer-job command that is neither
667 the first nor last command in this sequence
669 Note: it is recommended that the order of the receive-control-file sub-
670 command and the receive-data-file sub-command be configurable because
671 either order fails for some print systems. Some print systems assume
672 that the control file follows all data files and start printing
673 immediately on receipt of the control file. When such a print system
674 tries to print a data file that has not arrived, it produces an error.
676 Other print systems assume that the control file arrives before the data
677 files and start printing when the first data file arrives. Such a system
678 ignores the control information, such as banner page or copies.
680 NOTE: This specification does not define the mapping between the IPP
681 printer-uri and the LPD printer-name.
683 The mapper SHALL send the IPP parameters and attributes received from
684 the operation to the LPD printer by using the LPD receive-control-file
685 sub-command. The mapper SHALL create the LPD job-number for use in the
686 control file name, but the receiving printer MAY, in some circumstances,
687 assign a different job-number to the job. The mapper SHALL create the
688 IPP job-id and IPP job-uri returned in the Print-Job response.
690 NOTE: This specification does not specify how the mapper determines the
691 LPD job-number, the IPP job-id or the IPP job-uri of a job that it
692 creates nor does it specify the relation ship between the IPP job-uri,
693 IPP the job-id and the LPD job-number, both of which the mapper creates.
694 However, it is likely that the mapper will use the same integer value
695 for both theLPD job-number and the IPP job-id, and that the IPP Job-uri
696 is the printer's URI with the job-id concatenated on the end.
698 The mapper SHALL send data received in the IPP operation to the LPD
699 printer by using the LPD receive-data-file sub-command. The mapper SHALL
700 specify the exact number of bytes being transmitted in the number-of-
701 bytes field of the receive-data-file sub-command. It SHALL NOT use a
702 value of 0 in this field.
704 If the mapper, while it is transmitting a receive-a-printer-job command
705 or sub-command, either detects that its IPP connection has closed or
706 receives a Cancel-Job operation, the mapper SHALL terminate the LPD job
707 either with the abort sub-command or the remove-jobs command.
709 ISSUE: error code conversion.
711 5.2 Print-URI
713 The mapper SHALL handle this operation in the same way as a Print-Job
714 operation except that it SHALL obtain data referenced by the "document-
715 uri" parameter and SHALL then treat that data as if it had been received
716 via a Print-Job operation.
718 5.3 Validate-Job
720 The mapper SHALL perform this operation directly. Because LPD supports
721 very few attributes, this operation doesn't have much to check.
723 5.4 Create-Job
725 The mapper SHALL handle this operation like Print-Job, except
726 . the mapper SHALL send the control file after it has received
727 the last Send-Document or Send-URI operation because the
728 control file contains all the document-name and document-
729 format values specified in the Send-Document and Send-URI
730 operations.
731 . the mapper SHALL perform one receive-data-file sub-command for
732 each Send-Document or Send-URI operation received and in the
733 same order received.
734 . the mapper SHALL send the control file either before all data
735 files or after all data files.
736 (See the note in the section on Print-Job about the dilemma of
737 sending the control file either before or after the data
738 files.
740 5.5 Send-Document
742 The mapper performs a receive-data-file sub-command on the received
743 data. See the preceding section 5.4 "Create-Job" for the details.
745 5.6 Send-URI
747 The mapper SHALL obtain the data referenced by the "document-uri"
748 parameter, and SHALL then treat that data as if it had been received via
749 a Send-Document operation. See the preceding section 5.5 "Send-Document"
750 for the details.
752 5.7 Cancel-Job
754 The mapper SHALL perform a remove-jobs command with the following
755 parameters:
757 . the printer is the one to which the job was submitted, that is
758 the IPP printer-uri is mapped to an LPD printer-name by the
759 same mechanism as for all commands. ,
760 . the agent is the authenticated user-name of the IPP client,
761 . the job-number is the job-id returned by the Print-Job
762 command, that is, the LPD job-number has the same value as the
763 IPP job-id for likely implementations. .
765 5.8 Get-Printer-Attributes
767 LPD severely limits the set of attributes that the mapper is able to
768 return in its response for this operation. The mapper SHALL support, at
769 most, the following printer attributes:
771 . printer-state
772 . printer-state-reasons
774 The mapper uses either the long or short form of the "send queue state"
775 command.
777 The mapper SHALL assume that the LPD response that it receives has the
778 format and information specified in section 3.3 "Send queue state
779 (short)" and section 3.4 "Send queue state (long)". The mapper SHALL
780 determine the value of each requested attribute by using the inverse of
781 the mapping specified in the two aforementioned sections.
783 Note: the mapper can determine the response from the printer-status line
784 without examining the rest of the LPD response.
786 5.9 Get-Job-Attributes
788 LPD severely limits the set of attributes that the mapper is able to
789 return in its response for this operation. The mapper SHALL support, at
790 most, the following job attributes:
792 . number-of-intervening-jobs
793 . job-originating-user-name
794 . job-id
795 . document-name
796 . job-k-octets
797 . copies
799 The mapper uses either the long or short form of the "send queue state"
800 command. If it receives a request for the "job-k-octets" or "copies"
801 and supports the attribute it SHALL use the long form; otherwise, it
802 SHALL use the short form.
804 Note: the value of job-k-octets is the value in the short form divided
805 by the number of "copies" which is on the long form only. Its value can
806 also be determined by adding the "size" field values for each document
807 in the job in the long form.
809 The mapper SHALL assume that the LPD response that it receives has the
810 format and information specified in section 3.3 "Send queue state
811 (short)" and section 3.4 "Send queue state (long)". The mapper SHALL
812 determine the value of each requested attribute by using the inverse of
813 the mapping specified in the two aforementioned sections.
815 Note: when the mapper uses the LPD short form, it can determine the
816 response from the single LPD line that pertains to the job specified by
817 the Get-Job-Attributes operation.
819 NOTE: the mapper can use its correspondence between the IPP job-id, job-
820 uri and the LPD job-number.
822 5.10 Get-Jobs
824 The mapper SHALL perform this operation in the same way as Get-Job-
825 Attributes except that the mapper converts all the LPD job-lines, and
826 the IPP response contains one job object for each job-line in the LPD
827 response..
829 6. Mapping of IPP Parameters to LPD Control File Lines
831 This section describes the mapping from IPP operation input parameters
832 to LPD control file lines (called `functions'). The mapper receives the
833 IPP operation input parameters via the IPP operation. Each of the IPP
834 operation input parameters appear as sub-sections of section 3 and 4.2
835 in the IPP model document [ipp-mod].
837 In the context of LPD control file lines, the text operands have a
838 maximum length of 31 or 99 while IPP input parameters have a maximum of
839 255 characters. Therefore, there may be some data loss if the IPP
840 parameters exceed the maximum length of the LPD equivalent operands.
842 The mapper converts each supported IPP parameter to its corresponding
843 LPD function as defined by tables in the subsections that follow. These
844 subsections group functions according to whether they are:
846 . required with a job,
847 . optional with a job
848 . required with each document.
850 In the tables below, each IPP value is given a name, such as `h'. If an
851 LPD value uses the IPP value, then the LPD value column contains the IPP
852 name, such as `h' to denote this. Otherwise, the LPD value column
853 specifies the literal value.
855 6.1 Required Job Functions
857 The mapper SHALL include the following LPD functions with each job, and
858 they SHALL have the specified value. They SHALL be the first functions
859 in the control file and they SHALL be in the order "H" and then "P".
861 IPP LPD function
862 name value name value description
864 (perhaps in security h H gateway host Originating Host
865 layer)
866 requesting-user-name u P u User identification
867 and in the security
868 layer
870 A mapper SHALL sends its own host rather than the client's host, because
871 some LPD systems require that it be the same as the host from which the
872 remove-jobs command comes. A mapper MAY send its own user name as user
873 identification rather than the client user. But in any case, the values
874 sent SHALL be compatible with the LPD remove-jobs operation.
876 6.2 Optional Job Functions
878 The mapper MAY include the following LPD functions with each job. They
879 SHALL have the specified value if they are sent. These functions, if
880 present, SHALL follow the require job functions, and they SHALL precede
881 the required document functions.
883 IPP attribute LPD function
884 name value nam value description
885 e
887 job-name j J j Job name for banner
888 page
889 job-sheets `standard' L u Print banner page
890 job-sheets `none' omit `L' function
891 Note: `L' has special meaning when it is omitted. If `J' is omitted,
892 some undefined behavior occurs with respect to the banner page.
894 6.3 Required Document Functions
896 The mapper SHALL include one set of the following LPD functions with
897 each document, and they SHALL have the specified values. For each
898 document, the order of the functions SHALL be `f', `U' and then `N',
899 where `f' is replicated once for each copy.
901 IPP attribute LPD function
902 name value name value description
904 document- 'application/octet- f fff Print formatted file
905 format stream' or
906 'application/PostScrip
907 t'
908 copies c replicate `f' `c'
909 times
910 none U fff Unlink data file
911 document- n N n Name of source file
912 name
913 Note: the value `fff' of the `f' and `U' functions is the name of the
914 data file as transferred, e.g. "dfA123woden".
916 Note: the mapper SHALL not send the `o' function
918 ISSUE: should we register DVI, troff or ditroff?
920 If the mapper receives no "ipp-attribute-fidelitybest-effort" or it has
921 a value of false, then the mapper SHALL reject the job if it specifies
922 attributes or attribute values that are not among those supported in the
923 above tables.
925 Below is an example of the minimal control file for a job with three
926 copies of two files `foo' and `bar':
928 H tiger
929 P jones
930 f dfA123woden
931 f dfA123woden
932 f dfA123woden
933 U dfA123woden
934 N foo
935 f dfB123woden
936 f dfB123woden
937 f dfB123woden
938 U dfB123woden
939 N bar
941 7. Security
943 There are no security issues beyond those covered in the IPP protocol
944 document [ipp-pro], the IPP model document [ipp-mod] and the LPD
945 document [rfc1179].
947 8. References
949 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
950 "Internet Printing Protocol/1.0: Model and Semantics", , November 1997.
953 [ipp-pro] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet
954 Printing Protocol/1.0: Protocol specification", , November 1997.
957 [rfc1179] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179,
958 August 1990.
960 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and
961 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
963 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate
964 Requirement Levels", RFC 2119 , March 1997
966 [abnf] D. Crocker et al., "Augmented BNF for Syntax Specifications:
967 ABNF", draft-ietf-drums-abnf-05.txt.
969 9. Author's Addresses
971 Robert Herriot (editor) Norm Jacobs
972 Sun Microsystems Inc. Sun Microsystems Inc.
973 901 San Antonio.Road., MPK-17 1430 Owl Ridge Rd.
974 Mountain View, CA 94043 Colorado Springs, CO 80919
976 Phone: 650-786-8995 Phone: 719-532-9927
977 Fax: 650-786-7077 Fax: 719-535-0956
978 Email: robert.herriot@eng.sun.com Email:
979 Norm.Jacobs@Central.sun.com
981 Thomas N. Hastings Jay Martin
982 Xerox Corporation Underscore, Inc.
984 701 S. Aviation Blvd., ESAE-231 41-C Sagamore Park Road
985 El Segundo, CA 90245 Hudson, NH 03051-4915
987 Phone: 310-333-6413 Phone: 603-889-7000
988 Fax: 310-333-5514 Fax: 603-889-2699
989 EMail: hastings@cp10.es.xerox.com Email: jkm@underscore.com
991 10. Appendix A: ABNF Syntax for response of Send-queue-state (short)
993 The syntax in ABNF for the response to the LPD command `send-queue-state
994 (long)' is:
996 status-response = empty-queue / nonempty-queue
997 empty-queue = "no-entries" LF
998 nonempty-queue = printer-status LF heading LF *(job LF)
999 printer-status = OK-status / error-status
1000 OK-status = printer-name SP "ready and printing" LF
1001 error-status = < implementation dependent status information >
1002 heading = "Rank" 3SP Owner " " 6SP "Job" 13SP "Files"
1003 23SP "Total Size" LF
1004 ; the column headings and their values below begin
1005 at the columns
1006 ; 1, 8, 19, 35 and 63
1007 job = rank *SP owner *SP job *SP files *SP total-size "bytes"
1008 ; jobs are in order of oldest to newest
1009 rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1010 ; job that is printing is "active"
1011 ; other values show position in the queue
1012 owner =
1013 job = 1*3DIGIT ; job-number
1014 files = *( "," ) ; truncated to 24 characters
1015 total-size = 1*DIGIT ; combined size in bytes of all documents
1017 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)
1019 The syntax in ABNF for the response to the LPD command `send-queue-state
1020 (long)' is:
1022 status-response = empty-queue / nonempty-queue
1023 empty-queue = "no-entries" LF
1024 nonempty-queue = printer-status LF *job
1025 printer-status = OK-status / error-status
1026 OK-status = printer-name SP "ready and printing" LF
1027 error-status = < implementation dependent status information >
1028 job = LF line-1 LF line-2 LF
1029 line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
1030 line-2 = file-name 1*SP document-size "bytes"
1031 ; jobs are in order of oldest to newest
1032 rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1033 ; job that is printing is "active"
1034 ; other values show position in the queue
1035 owner =
1036 job = 1*3DIGIT
1037 file-name = [ 1*DIGIT "copies of" SP ]
1038 ; truncated to 24 characters
1039 document-size = 1*DIGIT ;size of single copy of the document.
1041 12. Appendix C: Unsupported LPD functions
1043 The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper
1044 ignores them and the IPP-to-LPD mapper does not send them.
1046 LPD command
1047 name description
1049 C Class for banner page
1050 I Indent Printing
1051 H Host of client
1052 M Mail when printed
1053 S Symbolic link data
1054 T Title for pr
1055 W Width of output
1056 1 troff R font
1057 2 troff I font
1058 3 troff B font
1059 4 troff S font
1061 The follow LPD functions specify document-formats which have no IPP
1062 equivalent, unless someone registers them. The LPD-to-IPP mapper rejects
1063 jobs that request such a document format, and the IPP-to-LPD mapper does
1064 not send them.
1066 LPD command
1067 name description
1069 c Plot CIF file
1070 d Print DVI file
1071 g Plot file
1072 k reserved for Kerberized clients and servers
1073 n Print ditroff output file
1074 p Print file with 'pr' format
1075 r File to print with FORTRAN carriage control
1076 t Print troff output file
1077 v Print raster file
1078 z reserved for future use with the Palladium
1079 print system
1081 13. Appendix D: Full Copyright Statement
1083 Copyright (C)The Internet Society (1997). All Rights Reserved
1085 This document and translations of it may be copied and furnished to
1086 others, and derivative works that comment on or otherwise explain it or
1087 assist in its implementation may be prepared, copied, published and
1088 distributed, in whole or in part, without restriction of any kind,
1089 provided that the above copyright notice and this paragraph are included
1090 on all such copies and derivative works. However, this document itself
1091 may not be modified in any way, such as by removing the copyright notice
1092 or references to the Internet Society or other Internet organizations,
1093 except as needed for the purpose of developing Internet standards in
1094 which case the procedures for copyrights defined in the Internet
1095 Standards process must be followed, or as required to translate it into
1096 languages other than English.
1098 The limited permissions granted above are perpetual and will not be
1099 revoked by the Internet Society or its successors or assigns.
1101 This document and the information contained herein is provided on an "AS
1102 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
1103 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
1104 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
1105 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
1106 FITNESS FOR A PARTICULAR PURPOSE.