]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group R. Herriot | |
8 | Request For Comments: 2569 Xerox Corporation | |
9 | Category: Experimental N. Jacobs | |
10 | Sun Microsystems, Inc. | |
11 | T. Hastings | |
12 | Xerox Corporation | |
13 | J. Martin | |
14 | Underscore, Inc. | |
15 | April 1999 | |
16 | ||
17 | ||
18 | Mapping between LPD and IPP Protocols | |
19 | ||
20 | Status of this Memo | |
21 | ||
22 | This memo defines an Experimental Protocol for the Internet | |
23 | community. It does not specify an Internet standard of any kind. | |
24 | Discussion and suggestions for improvement are requested. | |
25 | Distribution of this memo is unlimited. | |
26 | ||
27 | Copyright Notice | |
28 | ||
29 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
30 | ||
31 | IESG Note | |
32 | ||
33 | This document defines an Experimental protocol for the Internet | |
34 | community. The IESG expects that a revised version of this protocol | |
35 | will be published as Proposed Standard protocol. The Proposed | |
36 | Standard, when published, is expected to change from the protocol | |
37 | defined in this memo. In particular, it is expected that the | |
38 | standards-track version of the protocol will incorporate strong | |
39 | authentication and privacy features, and that an "ipp:" URL type will | |
40 | be defined which supports those security measures. Other changes to | |
41 | the protocol are also possible. Implementors are warned that future | |
42 | versions of this protocol may not interoperate with the version of | |
43 | IPP defined in this document, or if they do interoperate, that some | |
44 | protocol features may not be available. | |
45 | ||
46 | The IESG encourages experimentation with this protocol, especially in | |
47 | combination with Transport Layer Security (TLS) [RFC 2246], to help | |
48 | determine how TLS may effectively be used as a security layer for | |
49 | IPP. | |
50 | ||
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Herriot, et al. Experimental [Page 1] | |
59 | \f | |
60 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
61 | ||
62 | ||
63 | Abstract | |
64 | ||
65 | This document is one of a set of documents, which together describe | |
66 | all aspects of a new Internet Printing Protocol (IPP). IPP is an | |
67 | application level protocol that can be used for distributed printing | |
68 | using Internet tools and technologies. This document gives some | |
69 | advice to implementers of gateways between IPP and LPD (Line Printer | |
70 | Daemon). This document describes the mapping between (1) the commands | |
71 | and operands of the 'Line Printer Daemon (LPD) Protocol' specified in | |
72 | RFC 1179 and (2) the operations, operation attributes and job | |
73 | template attributes of the Internet Printing Protocol/1.0 (IPP). One | |
74 | of the purposes of this document is to compare the functionality of | |
75 | the two protocols. Another purpose is to facilitate implementation | |
76 | of gateways between LPD and IPP. | |
77 | ||
78 | WARNING: RFC 1179 was not on the IETF standards track. While RFC | |
79 | 1179 was intended to record existing practice, it fell short in some | |
80 | areas. However, this specification maps between (1) the actual | |
81 | current practice of RFC 1179 and (2) IPP. This document does not | |
82 | attempt to map the numerous divergent extensions to the LPD protocol | |
83 | that have been made by many implementers. | |
84 | ||
85 | The full set of IPP documents includes: | |
86 | ||
87 | Design Goals for an Internet Printing Protocol [RFC2567] | |
88 | Rationale for the Structure and Model and Protocol for the | |
89 | Internet Printing Protocol [RFC2568] | |
90 | Internet Printing Protocol/1.0: Model and Semantics [RFC2566] | |
91 | Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] | |
92 | Internet Printing Protocol/1.0: Implementors Guide [ipp-iig] | |
93 | Mapping between LPD and IPP Protocols (this document) | |
94 | ||
95 | The document, "Design Goals for an Internet Printing Protocol", takes | |
96 | a broad look at distributed printing functionality, and it enumerates | |
97 | real-life scenarios that help to clarify the features that need to be | |
98 | included in a printing protocol for the Internet. It identifies | |
99 | requirements for three types of users: end users, operators, and | |
100 | administrators. It calls out a subset of end user requirements that | |
101 | are satisfied in IPP/1.0. Operator and administrator requirements are | |
102 | out of scope for version 1.0. | |
103 | ||
104 | The document, "Rationale for the Structure and Model and Protocol for | |
105 | the Internet Printing Protocol", describes IPP from a high level | |
106 | view, defines a roadmap for the various documents that form the suite | |
107 | of IPP specifications, and gives background and rationale for the | |
108 | IETF working group's major decisions. | |
109 | ||
110 | ||
111 | ||
112 | ||
113 | ||
114 | Herriot, et al. Experimental [Page 2] | |
115 | \f | |
116 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
117 | ||
118 | ||
119 | The document, "Internet Printing Protocol/1.0: Model and Semantics", | |
120 | describes a simplified model with abstract objects, their attributes, | |
121 | and their operations. It introduces a Printer and a Job object. The | |
122 | Job object supports multiple documents per Job. It also addresses | |
123 | security, internationalization, and directory issues. | |
124 | ||
125 | The document, "Internet Printing Protocol/1.0: Encoding and | |
126 | Transport", is a formal mapping of the abstract operations and | |
127 | attributes defined in the model document onto HTTP/1.1. It defines | |
128 | the encoding rules for a new Internet media type called ' | |
129 | application/ipp'. | |
130 | ||
131 | This document "Internet Printing Protocol/1.0: Implementer's Guide", | |
132 | gives advice to implementers of IPP clients and IPP objects. | |
133 | ||
134 | TABLE OF CONTENTS | |
135 | ||
136 | 1. Introduction.....................................................4 | |
137 | 2. Terminology......................................................5 | |
138 | 3. Mapping from LPD Commands to IPP Operations......................5 | |
139 | 3.1 Print any waiting jobs..........................................6 | |
140 | 3.2 Receive a printer job...........................................6 | |
141 | 3.2.1 Abort job.....................................................7 | |
142 | 3.2.2 Receive control file..........................................7 | |
143 | 3.2.3 Receive data file.............................................8 | |
144 | 3.3 Send queue state (short)........................................8 | |
145 | 3.4 Send queue state (long)........................................10 | |
146 | 3.5 Remove jobs....................................................12 | |
147 | 4. Mapping of LPD Control File Lines to IPP Operation and Job | |
148 | Template Attributes.............................................13 | |
149 | 4.1 Required Job Functions.........................................13 | |
150 | 4.2 Optional Job Functions.........................................14 | |
151 | 4.3 Required Document Functions....................................14 | |
152 | 4.4 Recommended Document Functions.................................16 | |
153 | 5. Mapping from IPP operations to LPD commands.....................16 | |
154 | 5.1 Print-Job......................................................16 | |
155 | 5.2 Print-URI......................................................18 | |
156 | 5.3 Validate-Job...................................................18 | |
157 | 5.4 Create-Job.....................................................18 | |
158 | 5.5 Send-Document..................................................18 | |
159 | 5.6 Send-URI.......................................................18 | |
160 | 5.7 Cancel-Job.....................................................18 | |
161 | 5.8 Get-Printer-Attributes.........................................19 | |
162 | 5.9 Get-Job-Attributes.............................................19 | |
163 | 5.10 Get-Jobs......................................................20 | |
164 | 6. Mapping of IPP Attributes to LPD Control File Lines.............20 | |
165 | 6.1 Required Job Functions.........................................21 | |
166 | 6.2 Optional Job Functions.........................................21 | |
167 | ||
168 | ||
169 | ||
170 | Herriot, et al. Experimental [Page 3] | |
171 | \f | |
172 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
173 | ||
174 | ||
175 | 6.3 Required Document Functions....................................22 | |
176 | 7. Security Considerations.........................................23 | |
177 | 8. References......................................................23 | |
178 | 9. Authors' Addresses..............................................24 | |
179 | 10.Appendix A: ABNF Syntax for response of Send-queue-state (short)25 | |
180 | 11.Appendix B: ABNF Syntax for response of Send-queue-state (long) 26 | |
181 | 12.Appendix C: Unsupported LPD functions...........................27 | |
182 | 13.Full Copyright Statement........................................28 | |
183 | ||
184 | 1. Introduction | |
185 | ||
186 | The reader of this specification is expected to be familiar with the | |
187 | IPP Model and Semantics specification [RFC2566], the IPP Encoding and | |
188 | Transport [RF2565], and the Line Printer Daemon (LPD) protocol | |
189 | specification [RFC1179] as described in RFC 1179. | |
190 | ||
191 | RFC 1179 was written in 1990 in an attempt to document existing LPD | |
192 | protocol implementations. Since then, a number of undocumented | |
193 | extensions have been made by vendors to support functionality | |
194 | specific to their printing solutions. All of these extensions | |
195 | consist of additional control file commands. This document does not | |
196 | address any of these vendor extensions. Rather it addresses existing | |
197 | practice within the context of the features described by RFC 1179. | |
198 | Deviations of existing practice from RFC 1179 are so indicated. | |
199 | ||
200 | Other LPD control file commands in RFC 1179 are obsolete. They are | |
201 | intended to work on "text" only formats and are inappropriate for | |
202 | many contemporary document formats that completely specify each page. | |
203 | This document does not address the support of these obsolete | |
204 | features. | |
205 | ||
206 | In the area of document formats, also known as page description | |
207 | languages (PDL), RFC 1179 defines a fixed set with no capability for | |
208 | extension. Consequently, some new PDL's are not supported, and some | |
209 | of those that are supported are sufficiently unimportant now that | |
210 | they have not been registered for use with the Printer MIB [RFC1759] | |
211 | and IPP [RFC2566] [RFC2565], though they could be registered if | |
212 | desired. See the Printer MIB specification [RFC1759] and/or the IPP | |
213 | Model specification [RFC2566] for instructions for registration of | |
214 | document-formats with IANA. IANA lists the registered document- | |
215 | formats as "printer languages". | |
216 | ||
217 | This document addresses the protocol mapping for both directions: | |
218 | mapping of the LPD protocol to the IPP protocol and mapping of the | |
219 | IPP protocol to the LPD protocol. The former is called the "LPD-to- | |
220 | IPP mapper" and the latter is called the "IPP-to-LPD mapper". | |
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Herriot, et al. Experimental [Page 4] | |
227 | \f | |
228 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
229 | ||
230 | ||
231 | This document is an informational document that is not on the | |
232 | standards track. It is intended to help implementers of gateways | |
233 | between IPP and LPD. It also provides an example, which gives | |
234 | additional insight into IPP. | |
235 | ||
236 | 2. Terminology | |
237 | ||
238 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
239 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
240 | document are to be interpreted as described in RFC 2119 [RFC2119]. | |
241 | ||
242 | RFC 1179 uses the word "command" in two contexts: for over-the-wire | |
243 | operations and for command file functions. This document SHALL use | |
244 | the word "command" for the former and the phrase "functions" for the | |
245 | latter. The syntax of the LPD commands is given using ABNF | |
246 | [RFC2234]. | |
247 | ||
248 | The following tokens are used in order to make the syntax more | |
249 | readable: | |
250 | ||
251 | LF stands for %x0A (linefeed) | |
252 | SP stands for %x20. (space) | |
253 | DIGIT stands for %x30-39 ("0" to "9") | |
254 | ||
255 | 3. Mapping from LPD Commands to IPP Operations | |
256 | ||
257 | This section describes the mapping from LPD commands to IPP | |
258 | operations. Each of the following sub-sections appear as sub- | |
259 | sections of section 5 of RFC 1179. | |
260 | ||
261 | The following table summarizes the IPP operation that the mapper uses | |
262 | when it receives an LPD command. Each section below gives more | |
263 | detail: | |
264 | ||
265 | LPD command IPP operation | |
266 | ||
267 | ||
268 | print-any-waiting-jobs ignore | |
269 | receive-a-printer-job Print-Job or Create-Job/Send-Document | |
270 | send queue state Get-Printer-Attributes and Get-Jobs | |
271 | (short or long) | |
272 | remove-jobs Cancel-Job | |
273 | ||
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Herriot, et al. Experimental [Page 5] | |
283 | \f | |
284 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
285 | ||
286 | ||
287 | 3.1 Print any waiting jobs | |
288 | ||
289 | Command syntax: | |
290 | ||
291 | print-waiting-jobs = %x01 printer-name LF | |
292 | ||
293 | This command causes the LPD daemon check its queue and print any | |
294 | waiting jobs. An IPP printer handles waiting jobs without such a | |
295 | nudge. | |
296 | ||
297 | If the mapper receives this LPD command, it SHALL ignore it and send | |
298 | no IPP operation. | |
299 | ||
300 | 3.2 Receive a printer job | |
301 | ||
302 | Command syntax: | |
303 | ||
304 | receive-job = %x02 printer-name LF | |
305 | ||
306 | The control file and data files mentioned in the following paragraphs | |
307 | are received via LPD sub-commands that follow this command. Their | |
308 | mapping to IPP commands and attributes is described later in this | |
309 | section. | |
310 | ||
311 | The mapper maps the 'Receive a printer job' command to either: | |
312 | ||
313 | - the Print-Job operation which includes a single data file or | |
314 | - the Create-Job operation followed by one Send-Document operation | |
315 | for each data file. | |
316 | ||
317 | If the IPP printer supports both Create-Job and Send-Document, and if | |
318 | a job consists of: | |
319 | ||
320 | - a single data file, the mapper SHOULD use the Print-Job | |
321 | operation, but MAY use the Create-Job and Send-Document | |
322 | operations. | |
323 | - more than one data file, the mapper SHALL use Create-Job | |
324 | followed by one Send-Document for each received LPD data file. | |
325 | ||
326 | If the IPP printer does not support both Create-Job and Send- | |
327 | Document, and if a job consists of: | |
328 | ||
329 | - a single data file, the mapper SHALL use the PrintJob | |
330 | operation. | |
331 | - more than one data file, the mapper SHALL submit each received | |
332 | LPD data file as a separate Print-Job operation (thereby | |
333 | converting a single LPD job into multiple IPP jobs). | |
334 | ||
335 | ||
336 | ||
337 | ||
338 | Herriot, et al. Experimental [Page 6] | |
339 | \f | |
340 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
341 | ||
342 | ||
343 | If the mapper uses Create-Job and Send-Document, it MUST send the | |
344 | Create-Job operation before it sends any Send-Document operations | |
345 | whether the LPD control file, which supplies attributes for Create- | |
346 | Job, arrives before or after all LPD data files. | |
347 | ||
348 | NOTE: This specification does not specify how the mapper maps: the | |
349 | LPD Printer-name operand to the IPP "printer-uri" operation | |
350 | attribute. | |
351 | ||
352 | The following three sub-sections gives further details about the | |
353 | mapping from LPD receive-a-printer-job sub-commands. Each of the | |
354 | following subsections appear as sub-sections of section 6 of RFC | |
355 | 1179. | |
356 | ||
357 | 3.2.1 Abort job | |
358 | ||
359 | Sub-command syntax: | |
360 | ||
361 | abort-job = %x1 LF | |
362 | ||
363 | This sub-command of receive-a-printer-job is intended to abort any | |
364 | job transfer in process. | |
365 | ||
366 | If the mapper receives this sub-command, it SHALL cancel the job that | |
367 | it is in the process of transmitting. | |
368 | ||
369 | If the mapper is in the process of sending a Print-Job or Create-Job | |
370 | operation, it terminates the job either by closing the connection, or | |
371 | performing the Cancel-Job operation with the job-uri that it received | |
372 | from the Print-Job or Create-Job operation. | |
373 | ||
374 | NOTE: This sub-command is implied if at any time the connection | |
375 | between the LPD client and server is terminated before an entire | |
376 | print job has been transferred via an LPD Receive-a-printer-job | |
377 | request. | |
378 | ||
379 | 3.2.2 Receive control file | |
380 | ||
381 | Sub-command syntax: | |
382 | ||
383 | receive-control-file = %x2 number-of-bytes SP name-of-control-file LF | |
384 | number-of-bytes = 1*DIGIT | |
385 | name-of-control-file = "cfA" job-number client-host-name | |
386 | ; e.g. "cfA123woden" | |
387 | job-number = 3DIGIT | |
388 | client-host-name = <a host name> | |
389 | ||
390 | ||
391 | ||
392 | ||
393 | ||
394 | Herriot, et al. Experimental [Page 7] | |
395 | \f | |
396 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
397 | ||
398 | ||
399 | This sub-command is roughly equivalent to the IPP Create-Job | |
400 | operation. | |
401 | ||
402 | The mapper SHALL use the contents of the received LPD control file to | |
403 | create IPP operation attribute and job template attribute values to | |
404 | transmit with the Print-Job or Create-Job operation. | |
405 | ||
406 | 3.2.3 Receive data file | |
407 | ||
408 | Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file | |
409 | ||
410 | receive-data-file = %x03 number-of-bytes SP name-of-data-file LF | |
411 | number-of-bytes = 1*DIGIT | |
412 | name-of-data-file = "df" letter job-number client-host-name | |
413 | ; e.g. "dfA123woden for the first file | |
414 | letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z" | |
415 | ; first file is "A", | |
416 | ; second "B", and 52nd file is "z" | |
417 | job-number = 3DIGIT | |
418 | client-host-name = <a host name> | |
419 | ||
420 | This sub-command is roughly equivalent to the IPP Send-Document | |
421 | operation. | |
422 | ||
423 | The mapper SHALL use the contents of the received LPD data file as | |
424 | the data to transmit with the IPP Print-Job or Send-Document | |
425 | operation. | |
426 | ||
427 | Although RFC 1179 alludes to a method for passing an unspecified | |
428 | length data file by using an octet-count of zero, no implementations | |
429 | support this feature. The mapper SHALL reject a job that has a value | |
430 | of 0 in the number-of-bytes field. | |
431 | ||
432 | 3.3 Send queue state (short) | |
433 | ||
434 | Command syntax: | |
435 | ||
436 | send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF | |
437 | ||
438 | The mapper's response to this command includes information about the | |
439 | printer and its jobs. RFC 1179 specifies neither the information nor | |
440 | the format of its response. This document requires the mapper to | |
441 | follow existing practice as specified in this document. | |
442 | ||
443 | The mapper SHALL produce a response in the following format which | |
444 | consists of a printer-status line optionally followed by a heading | |
445 | line, and a list of jobs. This format is defined by examples below. | |
446 | Appendix A contains the ABNF syntax. | |
447 | ||
448 | ||
449 | ||
450 | Herriot, et al. Experimental [Page 8] | |
451 | \f | |
452 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
453 | ||
454 | ||
455 | For an printer with no jobs, the response starts in column 1 and is: | |
456 | ||
457 | no entries | |
458 | ||
459 | For a printer with jobs, an example of the response is: | |
460 | ||
461 | killtree is ready and printing | |
462 | Rank Owner Job Files Total Size | |
463 | active fred 123 stuff 1204 bytes | |
464 | 1st smith 124 resume, foo 34576 bytes | |
465 | 2nd fred 125 more 99 bytes | |
466 | 3rd mary 126 mydoc 378 bytes | |
467 | 4th jones 127 statistics.ps 4567 bytes | |
468 | 5th fred 128 data.txt 9 bytes | |
469 | ||
470 | The column numbers of above headings and job entries are: | |
471 | ||
472 | | | | | | | |
473 | 01 08 19 35 63 | |
474 | ||
475 | The mapper SHALL produce each field above from the following IPP | |
476 | attribute: | |
477 | ||
478 | LPD field IPP attribute special conversion details | |
479 | ||
480 | printer- printer-state and For a printer-state of idle or | |
481 | status printer-state-reasons processing, the mapper SHALL use | |
482 | the formats above. For stopped, | |
483 | the mapper SHALL use printer- | |
484 | state-reasons to produce an | |
485 | unspecified format for the error. | |
486 | rank number-of- the mapper SHALL the format above | |
487 | intervening-jobs | |
488 | owner job-originating-user- unspecified conversion; job- | |
489 | name originating-user-name may be the | |
490 | mapper's user-name | |
491 | job job-id the mapper shall use the job-id | |
492 | files document-name the mapper shall create a comma | |
493 | separated list of the document- | |
494 | names and then truncate this list | |
495 | to the first 24 characters | |
496 | total- job-k- the mapper shall multiple the | |
497 | size octets*copies*1024 value of job-k-octets by 1024 and | |
498 | by the value of the "copies" | |
499 | attribute. | |
500 | ||
501 | ||
502 | ||
503 | ||
504 | ||
505 | ||
506 | Herriot, et al. Experimental [Page 9] | |
507 | \f | |
508 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
509 | ||
510 | ||
511 | A mapper SHOULD use the job attribute number-of-intervening-jobs | |
512 | rather than the job's position in a list of jobs to determine 'rank' | |
513 | because a Printer may omit jobs that it wants to keep secret. If a | |
514 | printer doesn't support the job attribute number-of-intervening-jobs, | |
515 | a mapper MAY use the job's position. | |
516 | ||
517 | Note: a Printer may set the value of job-originating-user-name to the | |
518 | authenticated user or to the value of "requesting-user-name", | |
519 | depending on the implementation and configuration. For a gateway, the | |
520 | authenticated user is the user-id of the gateway, but the | |
521 | "requesting-user-name" may contain the name of the user who is the | |
522 | gateway's client. | |
523 | ||
524 | In order to obtain the information specified above, The LPD-to-IPP | |
525 | mapper SHALL use the Get-Printer-Attributes operation to get | |
526 | printer-status and SHOULD use the Get-Jobs operation to get | |
527 | information about all of the jobs. If the LPD command contains job- | |
528 | numbers or user-names, the mapper MAY handle the filtering of the | |
529 | response. If the LPD command contains job-numbers but no user-names, | |
530 | the mapper MAY use Get-Job-Attributes on each converted job-number | |
531 | rather than Get-Jobs. If the LPD command contains a single user-name | |
532 | but no job-numbers, the mapper MAY use Get-Jobs with the my-jobs | |
533 | option if the server supports this option and if the server allows | |
534 | the client to be a proxy for the LPD user. | |
535 | ||
536 | NOTE: This specification does not define how the mapper maps the LPD | |
537 | Printer-name operand to the IPP "printer-uri" operation attribute. | |
538 | ||
539 | 3.4 Send queue state (long) | |
540 | ||
541 | Command syntax: | |
542 | ||
543 | send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF | |
544 | ||
545 | The mapper's response to this command includes information about the | |
546 | printer and its jobs. RFC 1179 specifies neither the information nor | |
547 | the format of its response. This document requires the mapper to | |
548 | follow existing practice as specified in this document. | |
549 | ||
550 | The mapper SHALL produce a response in the following format which | |
551 | consists of a printer-status line optionally followed a list of jobs, | |
552 | where each job consists of a blank line, a description line, and one | |
553 | line for each file. The description line contains the user-name, | |
554 | rank, job-number and host. This format is defined by examples below. | |
555 | Appendix B contain the ABNF syntax. | |
556 | ||
557 | ||
558 | ||
559 | ||
560 | ||
561 | ||
562 | Herriot, et al. Experimental [Page 10] | |
563 | \f | |
564 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
565 | ||
566 | ||
567 | For an printer with no jobs the response is: | |
568 | ||
569 | no entries | |
570 | ||
571 | For a printer with jobs, an example of the response is: | |
572 | ||
573 | killtree is ready and printing | |
574 | ||
575 | fred: active [job 123 tiger] | |
576 | 2 copies of stuff 602 bytes | |
577 | ||
578 | smith: 1st [job 124 snail] | |
579 | 2 copies of resume 7088 bytes | |
580 | 2 copies of foo 10200 bytes | |
581 | ||
582 | fred: 2nd [job 125 tiger] | |
583 | more 99 bytes | |
584 | ||
585 | The column numbers of above headings and job entries are: | |
586 | ||
587 | | | | | |
588 | 01 09 41 | |
589 | ||
590 | Although the format of the long form is different from the format of | |
591 | the short form, their fields are identical except for a) the copies | |
592 | and host fields which are only in the long form, and b) the "size" | |
593 | field contains the single copy size of each file. Thus the sum of | |
594 | the file sizes in the "size" field times the value of the "copies" | |
595 | field produces the value for the "Total Size" field in the short | |
596 | form. For fields other than the host and copies fields, see the | |
597 | preceding section. For the host field see the table below. | |
598 | ||
599 | LPD field IPP attribute special conversion details | |
600 | ||
601 | host unspecified conversion; job- | |
602 | originating-host may be the | |
603 | mapper's host | |
604 | copies copies the mapper shall assume the | |
605 | value of copies precedes the | |
606 | string "copies of "; otherwise, | |
607 | the value of copies is 1. | |
608 | ||
609 | NOTE: This specification does not define how the mapper maps the LPD | |
610 | Printer-name operand to the IPP printer-uri operation attribute. | |
611 | ||
612 | ||
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | Herriot, et al. Experimental [Page 11] | |
619 | \f | |
620 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
621 | ||
622 | ||
623 | 3.5 Remove jobs | |
624 | ||
625 | Command syntax: | |
626 | ||
627 | remove-jobs = %x05 printer-name SP agent | |
628 | *(SP(user-name / job-number)) LF | |
629 | ||
630 | The agent operand is the user-name of the user initiating the | |
631 | remove-jobs command. The special user-name 'root' indicates a | |
632 | privileged user who can remove jobs whose user-name differs from the | |
633 | agent. | |
634 | ||
635 | The mapper SHALL issue one Cancel-Job operation for each job | |
636 | referenced by the remove-jobs command. Each job-number in the | |
637 | remove-jobs command references a single job. Each user-name in the | |
638 | remove-jobs command implicitly references all jobs owned by the | |
639 | specified user. The active job is implicitly referenced when the | |
640 | remove-jobs command contains neither job-numbers nor user-names. The | |
641 | mapper MAY use Get-Jobs to determine the job-uri of implicitly | |
642 | referenced jobs. | |
643 | ||
644 | The mapper SHALL not use the agent name of 'root' when end-users | |
645 | cancel their own jobs. Violation of this rule creates a potential | |
646 | security violation, and it may cause the printer to issue a | |
647 | notification that misleads a user into thinking that some other | |
648 | person canceled the job. | |
649 | ||
650 | If the agent of a remove-jobs command for a job J is the same as the | |
651 | user name specified with the 'P' function in the control file for job | |
652 | J, then the mapper SHALL ensure that the initiator of the Cancel-Job | |
653 | command for job J is the same as job-originating-user for job J. | |
654 | ||
655 | Note: This requirement means that a mapper must be consistent in who | |
656 | the receiver perceives as the initiator of IPP operations. The mapper | |
657 | either acts as itself or acts on behalf of another user. The latter | |
658 | is preferable if it is possible. This consistency is necessary | |
659 | between Print-Job/Create-Job and Cancel-Job in order for Cancel-Job | |
660 | to work, but it is also desirable for other operations. For example, | |
661 | Get-Jobs may give more information about job submitted by the | |
662 | initiator of this operation. | |
663 | ||
664 | NOTE: This specification does not define how the mapper maps: (1) the | |
665 | LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number | |
666 | to the IPP "job-uri". | |
667 | ||
668 | NOTE: This specification does not specify how the mapper maps the LPD | |
669 | user-name to the IPP job-originating-user because the mapper may use | |
670 | its own user-name with jobs. | |
671 | ||
672 | ||
673 | ||
674 | Herriot, et al. Experimental [Page 12] | |
675 | \f | |
676 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
677 | ||
678 | ||
679 | 4. Mapping of LPD Control File Lines to IPP Operation and Job Template | |
680 | Attributes | |
681 | ||
682 | This section describes the mapping from LPD control file lines | |
683 | (called 'functions') to IPP operation attributes and job template | |
684 | attributes. The mapper receives the control file lines via the LPD | |
685 | receive-control-file sub-command. Each of the LPD functions appear | |
686 | as sub-sections of section 7 of RFC 1179. | |
687 | ||
688 | In LPD control file lines, the text operands have a maximum length of | |
689 | 31 or 99 while IPP operation attribute and job template attribute | |
690 | values have a maximum of 255 or 1023 octets, depending on the | |
691 | attribute syntax. Therefore, no data is lost. | |
692 | ||
693 | The mapper converts each supported LPD function to its corresponding | |
694 | IPP operation or job template attribute as defined by tables in the | |
695 | subsections that follow. These subsections group functions according | |
696 | to whether they are: | |
697 | ||
698 | - required with a job, | |
699 | - optional with a job | |
700 | - required with each document. | |
701 | ||
702 | In the tables below, each LPD value is given a name, such as 'h'. If | |
703 | an IPP value uses the LPD value, then the IPP value column contains | |
704 | the LPD name, such as 'h' to denote this. Otherwise, the IPP value | |
705 | column specifies the literal value. | |
706 | ||
707 | 4.1 Required Job Functions | |
708 | ||
709 | The following LPD functions MUST be in a received LPD job. The mapper | |
710 | SHALL receive each of the following LPD functions and SHALL include | |
711 | the information as a operation or job template attribute with each | |
712 | IPP job. The functions SHOULD be in the order 'H', 'P' and they | |
713 | SHOULD be the first two functions in the control file, but they MAY | |
714 | be anywhere in the control file and in any order: | |
715 | ||
716 | LPD function IPP | |
717 | name value description name value | |
718 | ||
719 | H h Originating Host h (in security layer) | |
720 | P u User identification requesting- u (and in security | |
721 | user-name layer) | |
722 | none ipp- 'true' | |
723 | attribute- | |
724 | fidelity | |
725 | ||
726 | ||
727 | ||
728 | ||
729 | ||
730 | Herriot, et al. Experimental [Page 13] | |
731 | \f | |
732 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
733 | ||
734 | ||
735 | A mapper MAY send its own host rather than the client's host, and a | |
736 | mapper MAY send its own user-name as user identification rather than | |
737 | the client user. But in any case, the values sent SHALL be compatible | |
738 | with the Cancel-Job operation. The IPP operation MAY have no way to | |
739 | specify an originating host-name. | |
740 | ||
741 | The mapper SHALL include ipp-attribute-fidelity = true so that it | |
742 | doesn't have to determine which attributes a printer supports. | |
743 | ||
744 | 4.2 Optional Job Functions | |
745 | ||
746 | The following LPD functions MAY be present in a received job. These | |
747 | functions SHOULD follow the required job functions and precede the | |
748 | document functions, but they MAY be anywhere in the control file. | |
749 | ||
750 | If the mapper receives such an LPD function, the mapper SHALL include | |
751 | the corresponding IPP attribute with the value converted as specified | |
752 | in the table below. If the mapper does not receive such an LPD | |
753 | attribute, the mapper SHALL NOT include the corresponding IPP | |
754 | attribute, except the 'L' LPD function whose absence has a special | |
755 | meaning as noted in the table. | |
756 | ||
757 | LPD function IPP | |
758 | name value description name value | |
759 | ||
760 | J j Job name for job-name j | |
761 | banner page | |
762 | L l Print banner page job-sheets 'standard' if 'L' is | |
763 | present | |
764 | 'none' if 'L' is present | |
765 | M m Mail When Printed IPP has no notification | |
766 | mechanism. To support | |
767 | this LPD feature, the | |
768 | gateway must poll using | |
769 | the Get-Job-Attributes | |
770 | operation. | |
771 | ||
772 | 4.3 Required Document Functions | |
773 | ||
774 | The mapper SHALL receive one set of the required document functions | |
775 | with each copy of a document, and SHALL include the converted | |
776 | information as operation or job template attributes with each IPP | |
777 | document. | |
778 | ||
779 | If the control file contains required and recommended document | |
780 | functions, the required functions SHOULD precede the recommended ones | |
781 | and if the job contains multiple documents, all the functions for | |
782 | ||
783 | ||
784 | ||
785 | ||
786 | Herriot, et al. Experimental [Page 14] | |
787 | \f | |
788 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
789 | ||
790 | ||
791 | each document are grouped together as shown in the example of section | |
792 | 6.3 "Required Document Functions". However, the document functions | |
793 | MAY be in any order. | |
794 | ||
795 | LPD function IPP | |
796 | name value description name value | |
797 | ||
798 | f fff Print formatted document-format 'application/octet- | |
799 | file stream' | |
800 | l fff Print file leaving document-format 'application/octet- | |
801 | control characters stream' | |
802 | o fff Print Postscript document-format 'application/PostScri | |
803 | output file pt' | |
804 | copies see note | |
805 | ||
806 | Note: In practice, the 'f' LPD function is often overloaded. It is | |
807 | often used with any format of document data including PostScript and | |
808 | PCL data. | |
809 | ||
810 | Note: In practice, the 'l' LPD function is often used as a rough | |
811 | equivalent to the 'f' function. | |
812 | ||
813 | Note: When RFC 1179 was written, no implementation supported the 'o' | |
814 | function; instead 'f' was used for PostScript. Windows NT now sends ' | |
815 | o' function for a PostScript file. | |
816 | ||
817 | Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name | |
818 | of the data file as transferred, e.g. "dfA123woden". | |
819 | ||
820 | If the mapper receives any other lower case letter, the mapper SHALL | |
821 | reject the job because the document contains a format that the mapper | |
822 | does not support. | |
823 | ||
824 | The mapper determines the number of copies by counting the number of | |
825 | occurrences of each 'fff' file with one of the lower-case functions | |
826 | above. For example, if 'f dfA123woden' occurs 4 times, then copies | |
827 | has a value of 4. Although the LPD protocol allows the value of | |
828 | copies to be different for each document, the commands and the | |
829 | receiving print systems don't support this. | |
830 | ||
831 | ||
832 | ||
833 | ||
834 | ||
835 | ||
836 | ||
837 | ||
838 | ||
839 | ||
840 | ||
841 | ||
842 | Herriot, et al. Experimental [Page 15] | |
843 | \f | |
844 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
845 | ||
846 | ||
847 | 4.4 Recommended Document Functions | |
848 | ||
849 | The mapper SHOULD receive one set of the recommended document | |
850 | functions with each document, and SHOULD include the converted | |
851 | information as an operation or job template attribute with each IPP | |
852 | document. The functions SHOULD be received in the order 'U' and 'N', | |
853 | but they MAY arrive in any order. | |
854 | ||
855 | LPD function IPP | |
856 | name value description name value | |
857 | ||
858 | U fff ignored | |
859 | N n Name of source file document-name n | |
860 | ||
861 | Note: the value 'fff' of the 'U' function is the name of the data | |
862 | file as transferred, e.g. "dfA123woden". | |
863 | ||
864 | 5. Mapping from IPP operations to LPD commands | |
865 | ||
866 | If the IPP-to-LPD mapper receives an IPP operation, the following | |
867 | table summarizes the LPD command that it uses. Each section below | |
868 | gives the detail. Each of the following sub-sections appear as sub- | |
869 | sections of section 3 in the document "Internet Printing | |
870 | Protocol/1.0: Model and Semantics" [RFC2566]. | |
871 | ||
872 | IPP operation LPD command | |
873 | ||
874 | Print-Job or Print-URI or receive-a-printer-job | |
875 | Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs | |
876 | Validate-Job implemented by the mapper | |
877 | Cancel-Job remove-jobs | |
878 | Get-Printer-Attributes, Get-Job- send queue state (short or long) | |
879 | Attributes or Get-Jobs | |
880 | ||
881 | 5.1 Print-Job | |
882 | ||
883 | The mapper SHALL send the following commands in the order listed | |
884 | below: | |
885 | ||
886 | - receive-a-printer-job command | |
887 | - both receive-control-file sub-command and receive-data-file | |
888 | sub-command (unspecified order, see Note below) | |
889 | - print-any-waiting-jobs command, except that if the mapper is | |
890 | sending a sequence of receive a printer-job commands, it MAY | |
891 | omit sending print-any-waiting-jobs after any receive a | |
892 | printer-job command that is neither the first nor last command | |
893 | in this sequence | |
894 | ||
895 | ||
896 | ||
897 | ||
898 | Herriot, et al. Experimental [Page 16] | |
899 | \f | |
900 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
901 | ||
902 | ||
903 | Note: it is recommended that the order of the receive-control-file | |
904 | subcommand and the receive-data-file sub-command be configurable | |
905 | because either order fails for some print systems. Some print systems | |
906 | assume that the control file follows all data files and start | |
907 | printing immediately on receipt of the control file. When such a | |
908 | print system tries to print a data file that has not arrived, it | |
909 | produces an error. Other print systems assume that the control file | |
910 | arrives before the data files and start printing when the first data | |
911 | file arrives. Such a system ignores the control information, such as | |
912 | banner page or copies. | |
913 | ||
914 | NOTE: This specification does not define the mapping between the IPP | |
915 | printer-uri and the LPD printer-name. | |
916 | ||
917 | The mapper SHALL send the IPP operation attributes and job template | |
918 | attributes received from the operation to the LPD printer by using | |
919 | the LPD receive-control-file sub-command. The mapper SHALL create the | |
920 | LPD job-number for use in the control file name, but the receiving | |
921 | printer MAY, in some circumstances, assign a different job-number to | |
922 | the job. The mapper SHALL create the IPP job-id and IPP job-uri | |
923 | returned in the Print-Job response. | |
924 | ||
925 | NOTE: This specification does not specify how the mapper determines | |
926 | the LPD job-number, the IPP job-id or the IPP job-uri of a job that | |
927 | it creates nor does it specify the relationship between the IPP job- | |
928 | uri, IPP the job-id and the LPD job-number, both of which the mapper | |
929 | creates. However, it is likely that the mapper will use the same | |
930 | integer value for both the LPD job-number and the IPP job-id, and | |
931 | that the IPP Job-uri is the printer's URI with the job-id | |
932 | concatenated on the end. | |
933 | ||
934 | The mapper SHALL send data received in the IPP operation to the LPD | |
935 | printer by using the LPD receive-data-file sub-command. The mapper | |
936 | SHALL specify the exact number of bytes being transmitted in the | |
937 | number-of-bytes field of the receive-data-file sub-command. It SHALL | |
938 | NOT use a value of 0 in this field. | |
939 | ||
940 | If the mapper, while it is transmitting a receive-a-printer-job | |
941 | command or sub-command, either detects that its IPP connection has | |
942 | closed or receives a Cancel-Job operation, the mapper SHALL terminate | |
943 | the LPD job either with the abort sub-command or the remove-jobs | |
944 | command. | |
945 | ||
946 | This document does not address error code conversion. | |
947 | ||
948 | ||
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Herriot, et al. Experimental [Page 17] | |
955 | \f | |
956 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
957 | ||
958 | ||
959 | 5.2 Print-URI | |
960 | ||
961 | The mapper SHALL handle this operation in the same way as a Print-Job | |
962 | operation except that it SHALL obtain data referenced by the | |
963 | "document-uri" operation attribute and SHALL then treat that data as | |
964 | if it had been received via a Print-Job operation. | |
965 | ||
966 | 5.3 Validate-Job | |
967 | ||
968 | The mapper SHALL perform this operation directly. Because LPD | |
969 | supports very few attributes, this operation doesn't have much to | |
970 | check. | |
971 | ||
972 | 5.4 Create-Job | |
973 | ||
974 | The mapper SHALL handle this operation like Print-Job, except: | |
975 | ||
976 | - the mapper SHALL send the control file after it has received the | |
977 | last Send-Document or Send-URI operation because the control | |
978 | file contains all the document-name and document-format values | |
979 | specified in the Send-Document and Send-URI operations. | |
980 | - the mapper SHALL perform one receive-data-file sub-command for | |
981 | each Send-Document or Send-URI operation received and in the | |
982 | same order received. | |
983 | - the mapper SHALL send the control file either before all data | |
984 | files or after all data files. (See the note in the section on | |
985 | Print-Job about the dilemma of sending the control file either | |
986 | before or after the data files. | |
987 | ||
988 | 5.5 Send-Document | |
989 | ||
990 | The mapper performs a receive-data-file sub-command on the received | |
991 | data. See the preceding section 5.4 "Create-Job" for the details. | |
992 | ||
993 | 5.6 Send-URI | |
994 | ||
995 | The mapper SHALL obtain the data referenced by the "document-uri" | |
996 | operation attribute, and SHALL then treat that data as if it had been | |
997 | received via a Send-Document operation. See the preceding section 5.5 | |
998 | "Send-Document" for the details. | |
999 | ||
1000 | 5.7 Cancel-Job | |
1001 | ||
1002 | The mapper SHALL perform a remove-jobs command with the following | |
1003 | operation attributes: | |
1004 | ||
1005 | ||
1006 | ||
1007 | ||
1008 | ||
1009 | ||
1010 | Herriot, et al. Experimental [Page 18] | |
1011 | \f | |
1012 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1013 | ||
1014 | ||
1015 | - the printer is the one to which the job was submitted, that is | |
1016 | the IPP printer-uri is mapped to an LPD printer-name by the same | |
1017 | mechanism as for all commands | |
1018 | - the agent is the authenticated user-name of the IPP client | |
1019 | - the job-number is the job-id returned by the Print-Job command, | |
1020 | that is, the LPD job-number has the same value as the IPP job-id | |
1021 | for likely implementations | |
1022 | ||
1023 | 5.8 Get-Printer-Attributes | |
1024 | ||
1025 | LPD severely limits the set of attributes that the mapper is able to | |
1026 | return in its response for this operation. The mapper SHALL support, | |
1027 | at most, the following printer attributes: | |
1028 | ||
1029 | - printer-state | |
1030 | - printer-state-reasons | |
1031 | ||
1032 | The mapper uses either the long or short form of the "send queue | |
1033 | state" command. | |
1034 | ||
1035 | The mapper SHALL assume that the LPD response that it receives has | |
1036 | the format and information specified in section 3.3 "Send queue state | |
1037 | (short)" and section 3.4 "Send queue state (long)". The mapper SHALL | |
1038 | determine the value of each requested attribute by using the inverse | |
1039 | of the mapping specified in the two aforementioned sections. | |
1040 | ||
1041 | Note: the mapper can determine the response from the printer-status | |
1042 | line without examining the rest of the LPD response. | |
1043 | ||
1044 | 5.9 Get-Job-Attributes | |
1045 | ||
1046 | LPD severely limits the set of attributes that the mapper is able to | |
1047 | return in its response for this operation. The mapper SHALL support, | |
1048 | at most, the following job attributes: | |
1049 | ||
1050 | - number-of-intervening-jobs | |
1051 | - job-originating-user-name | |
1052 | - job-id | |
1053 | - document-name | |
1054 | - job-k-octets | |
1055 | - copies | |
1056 | ||
1057 | The mapper uses either the long or short form of the "send queue | |
1058 | state" command. If it receives a request for the "job-k-octets" or | |
1059 | "copies" and supports the attribute it SHALL use the long form; | |
1060 | otherwise, it SHALL use the short form. | |
1061 | ||
1062 | ||
1063 | ||
1064 | ||
1065 | ||
1066 | Herriot, et al. Experimental [Page 19] | |
1067 | \f | |
1068 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1069 | ||
1070 | ||
1071 | Note: the value of job-k-octets is the value in the short form | |
1072 | divided by the number of "copies" which is on the long form only. Its | |
1073 | value can also be determined by adding the "size" field values for | |
1074 | each document in the job in the long form. | |
1075 | ||
1076 | The mapper SHALL assume that the LPD response that it receives has | |
1077 | the format and information specified in section 3.3 "Send queue state | |
1078 | (short)" and section 3.4 "Send queue state (long)". The mapper SHALL | |
1079 | determine the value of each requested attribute by using the inverse | |
1080 | of the mapping specified in the two aforementioned sections. | |
1081 | ||
1082 | Note: when the mapper uses the LPD short form, it can determine the | |
1083 | response from the single LPD line that pertains to the job specified | |
1084 | by the Get-Job-Attributes operation. | |
1085 | ||
1086 | Note: the mapper can use its correspondence between the IPP job-id, | |
1087 | job-uri and the LPD job-number. | |
1088 | ||
1089 | 5.10 Get-Jobs | |
1090 | ||
1091 | The mapper SHALL perform this operation in the same way as Get-Job- | |
1092 | Attributes except that the mapper converts all the LPD job-lines, and | |
1093 | the IPP response contains one job object for each job-line in the LPD | |
1094 | response. | |
1095 | ||
1096 | 6. Mapping of IPP Attributes to LPD Control File Lines | |
1097 | ||
1098 | This section describes the mapping from IPP operation attributes and | |
1099 | job template attributes to LPD control file lines (called ' | |
1100 | functions'). The mapper receives the IPP operation attributes and job | |
1101 | template atributes via the IPP operation. Each of the IPP operation | |
1102 | attributes and job template attributes appear as sub-sections of | |
1103 | section 3 and 4.2 in the IPP model document [RFC2566]. | |
1104 | ||
1105 | In the context of LPD control file lines, the text operands have a | |
1106 | maximum length of 31 or 99 while IPP operation attributes and job | |
1107 | template attributes have a maximum of 255 or 1023 octets, depending | |
1108 | on the attribute syntax. Therefore, there may be some data loss if | |
1109 | the IPP operation attribute and job template attribute values exceed | |
1110 | the maximum length of the LPD equivalent operands. | |
1111 | ||
1112 | The mapper converts each supported IPP operation attribute and job | |
1113 | template attribute to its corresponding LPD function as defined by | |
1114 | tables in the subsections that follow. These subsections group | |
1115 | functions according to whether they are: | |
1116 | ||
1117 | ||
1118 | ||
1119 | ||
1120 | ||
1121 | ||
1122 | Herriot, et al. Experimental [Page 20] | |
1123 | \f | |
1124 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1125 | ||
1126 | ||
1127 | - required with a job, | |
1128 | - optional with a job | |
1129 | - required with each document. | |
1130 | ||
1131 | In the tables below, each IPP value is given a name, such as 'h'. If | |
1132 | an LPD value uses the IPP value, then the LPD value column contains | |
1133 | the IPP name, such as 'h' to denote this. Otherwise, the LPD value | |
1134 | column specifies the literal value. | |
1135 | ||
1136 | 6.1 Required Job Functions | |
1137 | ||
1138 | The mapper SHALL include the following LPD functions with each job, | |
1139 | and they SHALL have the specified value. They SHALL be the first | |
1140 | functions in the control file and they SHALL be in the order "H" and | |
1141 | then "P". | |
1142 | ||
1143 | IPP LPD function | |
1144 | name value name value description | |
1145 | ||
1146 | (perhaps in security h H gateway host Originating Host | |
1147 | layer) | |
1148 | requesting-user-name u P u User identification | |
1149 | and in the security | |
1150 | layer | |
1151 | ||
1152 | A mapper SHALL sends its own host rather than the client's host, | |
1153 | because some LPD systems require that it be the same as the host from | |
1154 | which the remove-jobs command comes. A mapper MAY send its own user | |
1155 | name as user identification rather than the client user. But in any | |
1156 | case, the values sent SHALL be compatible with the LPD remove-jobs | |
1157 | operation. | |
1158 | ||
1159 | 6.2 Optional Job Functions | |
1160 | ||
1161 | The mapper MAY include the following LPD functions with each job. | |
1162 | They SHALL have the specified value if they are sent. These | |
1163 | functions, if present, SHALL follow the require job functions, and | |
1164 | they SHALL precede the required document functions. | |
1165 | ||
1166 | IPP attribute LPD function | |
1167 | name value name value description | |
1168 | ||
1169 | job-name j J j Job name for banner | |
1170 | page | |
1171 | job-sheets 'standard' L u Print banner page | |
1172 | job-sheets 'none' omit 'L' function | |
1173 | ||
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Herriot, et al. Experimental [Page 21] | |
1179 | \f | |
1180 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1181 | ||
1182 | ||
1183 | Note: 'L' has special meaning when it is omitted. If 'J' is omitted, | |
1184 | some undefined behavior occurs with respect to the banner page. | |
1185 | ||
1186 | 6.3 Required Document Functions | |
1187 | ||
1188 | The mapper SHALL include one set of the following LPD functions with | |
1189 | each document, and they SHALL have the specified values. For each | |
1190 | document, the order of the functions SHALL be 'f', 'U' and then 'N', | |
1191 | where 'f' is replicated once for each copy. | |
1192 | ||
1193 | IPP attribute LPD function | |
1194 | ||
1195 | name value name value description | |
1196 | ||
1197 | document- 'application/octet- f fff Print formatted file | |
1198 | format stream' or | |
1199 | 'application/PostScript' | |
1200 | copies c replicate 'f' 'c' | |
1201 | times | |
1202 | none U fff Unlink data file | |
1203 | document- n N n Name of source file | |
1204 | name | |
1205 | ||
1206 | Note: the value 'fff' of the 'f' and 'U' functions is the name of the | |
1207 | data file as transferred, e.g. "dfA123woden". | |
1208 | ||
1209 | Note: the mapper SHALL not send the 'o' function | |
1210 | ||
1211 | ISSUE: should we register DVI, troff or ditroff? | |
1212 | ||
1213 | If the mapper receives no "ipp-attribute-fidelitybest-effort" or it | |
1214 | has a value of false, then the mapper SHALL reject the job if it | |
1215 | specifies attributes or attribute values that are not among those | |
1216 | supported in the above tables. | |
1217 | ||
1218 | Below is an example of the minimal control file for a job with three | |
1219 | copies of two files 'foo' and 'bar': | |
1220 | ||
1221 | H tiger | |
1222 | P jones | |
1223 | f dfA123woden | |
1224 | f dfA123woden | |
1225 | f dfA123woden | |
1226 | U dfA123woden | |
1227 | N foo | |
1228 | f dfB123woden | |
1229 | f dfB123woden | |
1230 | f dfB123woden | |
1231 | ||
1232 | ||
1233 | ||
1234 | Herriot, et al. Experimental [Page 22] | |
1235 | \f | |
1236 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1237 | ||
1238 | ||
1239 | U dfB123woden | |
1240 | N bar | |
1241 | ||
1242 | 7. Security Considerations | |
1243 | ||
1244 | There are no security issues beyond those covered in the IPP Encoding | |
1245 | and Transport document [RFC2565], the IPP model document [RFC2566] | |
1246 | and the LPD document [RFC1179]. | |
1247 | ||
1248 | 8. References | |
1249 | ||
1250 | [ipp-iig] Hasting, T., et al., "Internet Printing Protocol/1.0: | |
1251 | Implementer's Guide", Work in Progress. | |
1252 | ||
1253 | [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J. | |
1254 | Gyllenskog, "Printer MIB", RFC 1759, March 1995. | |
1255 | ||
1256 | [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, | |
1257 | August 1990. | |
1258 | ||
1259 | [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate | |
1260 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
1261 | ||
1262 | [RFC2234] D. Crocker et al., "Augmented BNF for Syntax | |
1263 | Specifications: ABNF", RFC 2234, November 1997. | |
1264 | ||
1265 | [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet | |
1266 | Printing Protocol/1.0: Encoding and Transport", RFC 2565, | |
1267 | April 1999. | |
1268 | ||
1269 | [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. | |
1270 | Powell, "Internet Printing Protocol/1.0: Model and | |
1271 | Semantics", RFC 2566, April 1999. | |
1272 | ||
1273 | [RFC2567] Wright, D., "Design Goals for an Internet Printing | |
1274 | Protocol", RFC 2567, April 1999. | |
1275 | ||
1276 | [RFC2568] Zilles, S., "Rationale for the Structure and Model and | |
1277 | Protocol for the Internet Printing Protocol", RFC 2568, | |
1278 | April 1999. | |
1279 | ||
1280 | ||
1281 | ||
1282 | ||
1283 | ||
1284 | ||
1285 | ||
1286 | ||
1287 | ||
1288 | ||
1289 | ||
1290 | Herriot, et al. Experimental [Page 23] | |
1291 | \f | |
1292 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1293 | ||
1294 | ||
1295 | 9. Authors' Addresses | |
1296 | ||
1297 | Robert Herriot (Editor) | |
1298 | Xerox Corporation | |
1299 | 3400 Hillview Ave., Bldg #1 | |
1300 | Palo Alto, CA 94304 | |
1301 | ||
1302 | Phone: 650-813-7696 | |
1303 | Fax: 650-813-6860 | |
1304 | EMail: rherriot@pahv.xerox.com | |
1305 | ||
1306 | ||
1307 | Norm Jacobs | |
1308 | Sun Microsystems Inc. | |
1309 | 1430 Owl Ridge Rd. | |
1310 | Colorado Springs, CO 80919 | |
1311 | ||
1312 | Phone: 719-532-9927 | |
1313 | Fax: 719-535-0956 | |
1314 | EMail: Norm.Jacobs@Central.sun.com | |
1315 | ||
1316 | ||
1317 | Thomas N. Hastings | |
1318 | Xerox Corporation | |
1319 | 701 S. Aviation Blvd., ESAE-231 | |
1320 | El Segundo, CA 90245 | |
1321 | ||
1322 | Phone: 310-333-6413 | |
1323 | Fax: 310-333-5514 | |
1324 | EMail: hastings@cp10.es.xerox.com | |
1325 | ||
1326 | ||
1327 | Jay Martin | |
1328 | Underscore, Inc. | |
1329 | 41-C Sagamore Park Road | |
1330 | Hudson, NH 03051-4915 | |
1331 | ||
1332 | Phone: 603-889-7000 | |
1333 | Fax: 603-889-2699 | |
1334 | EMail: jkm@underscore.com | |
1335 | ||
1336 | ||
1337 | ||
1338 | ||
1339 | ||
1340 | ||
1341 | ||
1342 | ||
1343 | ||
1344 | ||
1345 | ||
1346 | Herriot, et al. Experimental [Page 24] | |
1347 | \f | |
1348 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1349 | ||
1350 | ||
1351 | 10. Appendix A: ABNF Syntax for response of Send-queue-state (short) | |
1352 | ||
1353 | The syntax in ABNF for the response to the LPD command 'send-queue- | |
1354 | state (long)' is: | |
1355 | ||
1356 | status-response = empty-queue / nonempty-queue | |
1357 | empty-queue = "no-entries" LF | |
1358 | nonempty-queue = printer-status LF heading LF *(job LF) | |
1359 | printer-status = OK-status / error-status | |
1360 | OK-status = printer-name SP "ready and printing" LF | |
1361 | error-status = < implementation dependent status information > | |
1362 | heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files" | |
1363 | 23SP "Total Size" LF | |
1364 | ; the column headings and their values below begin | |
1365 | at the columns | |
1366 | ; 1, 8, 19, 35 and 63 | |
1367 | job = rank *SP owner *SP job *SP files *SP total-size "bytes" | |
1368 | ; jobs are in order of oldest to newest | |
1369 | rank = "active" / "1st" / "2nd" / "3rd" / integer "th" | |
1370 | ; job that is printing is "active" | |
1371 | ; other values show position in the queue | |
1372 | owner = <user name of person who submitted the job> | |
1373 | job = 1*3DIGIT ; job-number | |
1374 | files = <file name> *( "," <file name>) ; truncated to 24 characters | |
1375 | total-size = 1*DIGIT ; combined size in bytes of all documents | |
1376 | ||
1377 | ||
1378 | ||
1379 | ||
1380 | ||
1381 | ||
1382 | ||
1383 | ||
1384 | ||
1385 | ||
1386 | ||
1387 | ||
1388 | ||
1389 | ||
1390 | ||
1391 | ||
1392 | ||
1393 | ||
1394 | ||
1395 | ||
1396 | ||
1397 | ||
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Herriot, et al. Experimental [Page 25] | |
1403 | \f | |
1404 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1405 | ||
1406 | ||
1407 | 11. Appendix B: ABNF Syntax for response of Send-queue-state (long) | |
1408 | ||
1409 | The syntax in ABNF for the response to the LPD command 'send-queue- | |
1410 | state (long)' is: | |
1411 | ||
1412 | status-response = empty-queue / nonempty-queue | |
1413 | empty-queue = "no-entries" LF | |
1414 | nonempty-queue = printer-status LF *job | |
1415 | printer-status = OK-status / error-status | |
1416 | OK-status = printer-name SP "ready and printing" LF | |
1417 | error-status = < implementation dependent status information > | |
1418 | job = LF line-1 LF line-2 LF | |
1419 | line-1 = owner ":" SP rank 1*SP "[job" job SP host "]" | |
1420 | line-2 = file-name 1*SP document-size "bytes" | |
1421 | ; jobs are in order of oldest to newest | |
1422 | rank = "active" / "1st" / "2nd" / "3rd" / integer "th" | |
1423 | ; job that is printing is "active" | |
1424 | ; other values show position in the queue | |
1425 | owner = <user name of person who submitted the job> | |
1426 | job = 1*3DIGIT | |
1427 | file-name = [ 1*DIGIT "copies of" SP ] <file name> | |
1428 | ; truncated to 24 characters | |
1429 | document-size = 1*DIGIT ;size of single copy of the document. | |
1430 | ||
1431 | ||
1432 | ||
1433 | ||
1434 | ||
1435 | ||
1436 | ||
1437 | ||
1438 | ||
1439 | ||
1440 | ||
1441 | ||
1442 | ||
1443 | ||
1444 | ||
1445 | ||
1446 | ||
1447 | ||
1448 | ||
1449 | ||
1450 | ||
1451 | ||
1452 | ||
1453 | ||
1454 | ||
1455 | ||
1456 | ||
1457 | ||
1458 | Herriot, et al. Experimental [Page 26] | |
1459 | \f | |
1460 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1461 | ||
1462 | ||
1463 | 12. Appendix C: Unsupported LPD functions | |
1464 | ||
1465 | The follow LPD functions have no IPP equivalent. The LPD-to-IPP | |
1466 | mapper ignores them and the IPP-to-LPD mapper does not send them. | |
1467 | ||
1468 | LPD command | |
1469 | name description | |
1470 | ||
1471 | C Class for banner page | |
1472 | I Indent Printing | |
1473 | H Host of client | |
1474 | M Mail when printed | |
1475 | S Symbolic link data | |
1476 | T Title for pr | |
1477 | W Width of output | |
1478 | 1 troff R font | |
1479 | 2 troff I font | |
1480 | 3 troff B font | |
1481 | 4 troff S font | |
1482 | ||
1483 | The follow LPD functions specify document-formats which have no IPP | |
1484 | equivalent, unless someone registers them. The LPD-to-IPP mapper | |
1485 | rejects jobs that request such a document format, and the IPP-to-LPD | |
1486 | mapper does not send them. | |
1487 | ||
1488 | LPD command | |
1489 | name description | |
1490 | ||
1491 | c Plot CIF file | |
1492 | d Print DVI file | |
1493 | g Plot file | |
1494 | k reserved for Kerberized clients and servers | |
1495 | n Print ditroff output file | |
1496 | p Print file with 'pr' format | |
1497 | r File to print with FORTRAN carriage control | |
1498 | t Print troff output file | |
1499 | v Print raster file | |
1500 | z reserved for future use with the Palladium | |
1501 | print system | |
1502 | ||
1503 | ||
1504 | ||
1505 | ||
1506 | ||
1507 | ||
1508 | ||
1509 | ||
1510 | ||
1511 | ||
1512 | ||
1513 | ||
1514 | Herriot, et al. Experimental [Page 27] | |
1515 | \f | |
1516 | RFC 2569 Mapping between LPD and IPP Protocols April 1999 | |
1517 | ||
1518 | ||
1519 | 13. Full Copyright Statement | |
1520 | ||
1521 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
1522 | ||
1523 | This document and translations of it may be copied and furnished to | |
1524 | others, and derivative works that comment on or otherwise explain it | |
1525 | or assist in its implementation may be prepared, copied, published | |
1526 | and distributed, in whole or in part, without restriction of any | |
1527 | kind, provided that the above copyright notice and this paragraph are | |
1528 | included on all such copies and derivative works. However, this | |
1529 | document itself may not be modified in any way, such as by removing | |
1530 | the copyright notice or references to the Internet Society or other | |
1531 | Internet organizations, except as needed for the purpose of | |
1532 | developing Internet standards in which case the procedures for | |
1533 | copyrights defined in the Internet Standards process must be | |
1534 | followed, or as required to translate it into languages other than | |
1535 | English. | |
1536 | ||
1537 | The limited permissions granted above are perpetual and will not be | |
1538 | revoked by the Internet Society or its successors or assigns. | |
1539 | ||
1540 | This document and the information contained herein is provided on an | |
1541 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
1542 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
1543 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
1544 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
1545 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
1546 | ||
1547 | ||
1548 | ||
1549 | ||
1550 | ||
1551 | ||
1552 | ||
1553 | ||
1554 | ||
1555 | ||
1556 | ||
1557 | ||
1558 | ||
1559 | ||
1560 | ||
1561 | ||
1562 | ||
1563 | ||
1564 | ||
1565 | ||
1566 | ||
1567 | ||
1568 | ||
1569 | ||
1570 | Herriot, et al. Experimental [Page 28] | |
1571 | \f |