idnits 2.17.1
draft-ietf-ipp-lpd-ipp-map-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 23
longer pages, the longest (page 2) 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.
** The abstract seems to contain references ([ISO10175]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords -- however, there's a paragraph with a matching beginning.
Boilerplate error?
RFC 2119 keyword, line 249: '...le, the mapper SHOULD use the Pri...'
RFC 2119 keyword, line 250: '...operation, but MAY use the Create...'
RFC 2119 keyword, line 252: '...le, the mapper MUST use Create-Job...'
RFC 2119 keyword, line 258: '...e, the mapper MUST use the Prin...'
RFC 2119 keyword, line 260: '...file, the mapper MUST submit each rec...'
(91 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 199 has weird spacing: '...ommands to IP...'
== Line 226 has weird spacing: '...If the mapper...'
== Line 243 has weird spacing: '...ate-Job opera...'
== Line 249 has weird spacing: '... single data ...'
== Line 250 has weird spacing: '...AY use the ...'
== (42 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 'MUST not' in this paragraph:
The mapper MUST 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.
-- 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 (June 30, 1998) is 9431 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)
-- Missing reference section? 'ISO10175' on line 42 looks like a reference
Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 INTERNET-DRAFT Robert Herriot (editor)
2 Sun Microsystems, Inc.
3 draft-ietf-ipp-lpd-ipp-map-04.txt Tom Hastings
4 Xerox Corporation
5 Norm Jacobs
6 Sun Microsystems, Inc.
7 Jay Martin
8 Underscore, Inc.
9 June 30, 1998
11 Mapping between LPD and IPP Protocols
13 Status of this Memo
15 This document is an Internet-Draft. Internet-Drafts are working
16 documents of the Internet Engineering Task Force (IETF), its areas, and
17 its working groups. Note that other groups may also distribute working
18 documents as Internet-Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference material
23 or to cite them other than as "work in progress."
25 To learn the current status of any Internet-Draft, please check the
26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
28 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
29 ftp.isi.edu (US West Coast).
31 Copyright Notice
33 Copyright (C)The Internet Society (1997). All Rights Reserved.
35 Abstract
37 This document is one of a set of documents, which together describe all
38 aspects of a new Internet Printing Protocol (IPP). IPP is an application
39 level protocol that can be used for distributed printing using Internet
40 tools and technologies. The protocol is heavily influenced by the
41 printing model introduced in the Document Printing Application (DPA)
42 [ISO10175] standard. Although DPA specifies both end user and
43 administrative features, IPP version 1.0 (IPP/1.0) focuses only on end
44 user functionality.
46 The full set of IPP documents includes:
48 Design Goals for an Internet Printing Protocol [ipp-req]
49 (informational)
50 Rationale for the Structure and Model and Protocol for the Internet
51 Printing Protocol [ipp-rat] (informational)
52 Internet Printing Protocol/1.0: Model and Semantics [ipp mod]
53 Internet Printing Protocol/1.0: Encoding and Transport [ipp-pro]
54 Mapping between LPD and IPP Protocols (this document) (informational)
56 The design goals document, "Design Goals for an Internet Printing
57 Protocol", takes a broad look at distributed printing functionality, and
58 it enumerates real-life scenarios that help to clarify the features that
59 need to be included in a printing protocol for the Internet. It
60 identifies requirements for three types of users: end users, operators,
61 and administrators. The design goals document calls out a subset of end
62 user requirements that are satisfied in IPP/1.0. Operator and
63 administrator requirements are out of scope for version 1.0. The
64 rationale document, "Rationale for the Structure and Model and Protocol
65 for the Internet Printing Protocol", describes IPP from a high level
66 view, defines a roadmap for the various documents that form the suite of
67 IPP specifications, and gives background and rationale for the IETF
68 working group's major decisions. The document, "Internet Printing
69 Protocol/1.0: Model and Semantics", describes a simplified model with
70 abstract objects, their attributes, and their operations. The model
71 introduces a Printer and a Job. The Job supports multiple documents per
72 Job. The model document also addresses how security,
73 internationalization, and directory issues are addressed. The protocol
74 specification, "Internet Printing Protocol/1.0: Encoding and Transport",
75 is a formal mapping of the abstract operations and attributes defined in
76 the model document onto HTTP/1.1. The protocol specification defines the
77 encoding rules for a new Internet media type called "application/ipp".
79 The "Mapping between LPD and IPP Protocols" gives some advice to
80 implementors of gateways between IPP and LPD (Line Printer Daemon)
81 implementations. It specifies the mapping between (1) the commands and
82 operands of the "Line Printer Daemon (LPD) Protocol" specified in RFC
83 1179 and (2) the operations and parameters of the Internet Printing
84 Protocol (IPP). One of the purposes of this document is to compare the
85 functionality of the two protocols. Another purpose is to facilitate
86 implementation of gateways between LPD and IPP. This document also
87 provides an example, which gives additional insight into IPP
89 WARNING: RFC 1179 was not on standards track. While RFC 1179 was
90 intended to record existing practice, it fell short in some areas.
91 However, this specification maps between (1) the actual current practice
92 of RFC 1179 and (2) IPP. This document does not attempt to map the
93 numerous divergent extensions to the LPD protocol that have been made by
94 many implementers.
96 TABLE OF CONTENTS
98 1. Introduction .......................................................4
99 2. Terminology ........................................................4
100 3. Mapping from LPD Commands to IPP Operations ........................5
101 3.1 Print any waiting jobs............................................5
102 3.2 Receive a printer job.............................................5
103 3.2.1 Abort job....................................................6
104 3.2.2 Receive control file.........................................7
105 3.2.3 Receive data file............................................7
106 3.3 Send queue state (short)..........................................7
107 3.4 Send queue state (long)...........................................9
108 3.5 Remove jobs......................................................10
109 4. Mapping of LPD Control File Lines to IPP Parameters ...............11
110 4.1 Required Job Functions...........................................12
111 4.2 Optional Job Functions...........................................12
112 4.3 Required Document Functions......................................13
113 4.4 Recommended Document Functions...................................14
114 5. Mapping from IPP operations to LPD commands .......................14
115 5.1 Print-Job........................................................15
116 5.2 Print-URI........................................................16
117 5.3 Validate-Job.....................................................16
118 5.4 Create-Job.......................................................16
119 5.5 Send-Document....................................................16
120 5.6 Send-URI.........................................................17
121 5.7 Cancel-Job.......................................................17
122 5.8 Get-Printer-Attributes...........................................17
123 5.9 Get-Job-Attributes...............................................17
124 5.10 Get-Jobs .......................................................18
125 6. Mapping of IPP Parameters to LPD Control File Lines ...............18
126 6.1 Required Job Functions...........................................19
127 6.2 Optional Job Functions...........................................19
128 6.3 Required Document Functions......................................20
129 7. Security Considerations ...........................................21
130 8. References ........................................................21
131 9. Author's Addresses ................................................21
132 10.Appendix A: ABNF Syntax for response of Send-queue-state (short) ..22
133 11.Appendix B: ABNF Syntax for response of Send-queue-state (long) ...22
134 12.Appendix C: Unsupported LPD functions .............................23
135 13.Appendix D: Full Copyright Statement ..............................24
136 Mapping between the LPD and IPP Protocols
138 1. Introduction
140 The reader of this specification is expected to be familiar with the IPP
141 Model and Semantics specification [ipp-mod], the IPP Encoding and
142 Transport [ipp-pro], and the Line Printer Daemon (LPD) protocol
143 specification [rfc1179] as described in RFC 1179.
145 RFC 1179 was written in 1990 in an attempt to document existing LPD
146 protocol implementations. Since then, a number of undocumented
147 extensions have been made by vendors to support functionality specific
148 to their printing solutions. All of these extensions consist of
149 additional control file commands. This document does not address any of
150 these vendor extensions. Rather it addresses existing practice within
151 the context of the features described by RFC 1179. Deviations of
152 existing practice from RFC 1179 are so indicated.
154 Other LPD control file commands in RFC 1179 are obsolete. They are
155 intended to work on "text" only formats and are inappropriate for many
156 contemporary document formats that completely specify each page. This
157 document does not address the support of these obsolete features.
159 In the area of document formats, also known as page description
160 languages (PDL), RFC 1179 defines a fixed set with no capability for
161 extension. Consequently, some new PDL's are not supported, and some of
162 those that are supported are sufficiently unimportant now that they have
163 not been registered for use with the Printer MIB[rfc1759] and IPP[ipp-
164 mod] [ipp-pro], though they could be registered if desired. See the
165 Printer MIB specification [rfc1759] and/or the IPP Model specification
166 [ipp-mod] for instructions for registration of document-formats with
167 IANA. IANA lists the registered document-formats as "printer
168 languages".
170 This document addresses the protocol mapping for both directions:
171 mapping of the LPD protocol to the IPP protocol and mapping of the IPP
172 protocol to the LPD protocol. The former is called the "LPD-to-IPP
173 mapper" and the latter is called the "IPP-to-LPD mapper".
175 This document is an informational document that is not on the standards
176 track. It is intended to help implementors of gateways between IPP and
177 LPD. It also provides an example, which gives additional insight into
178 IPP.
180 2. Terminology
182 The key words "MUST", "MUST NOT", "REQUIRED", MUSTMUST"SHOULD", "SHOULD
183 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
184 interpreted as described in RFC 2119 [abnf].
186 RFC 1179 uses the word "command" in two contexts: for over-the-wire
187 operations and for command file functions. This document uses the word
188 "command" for the former and the phrase "functions" for the latter. The
189 syntax of the LPD commands is given using ABNF [abnf].
191 The following tokens are used in order to make the syntax more readable:
193 LF stands for %x0A (linefeed)
194 SP stands for %x20. (space)
195 DIGIT stands for %x30-39 ("0" to "9")
197 3. Mapping from LPD Commands to IPP Operations
199 This section describes the mapping from LPD commands to IPP operations.
200 Each of the following sub-sections appear as sub-sections of section 5
201 of RFC 1179.
203 The following table summarizes the IPP operation that the mapper uses
204 when it receives an LPD command. Each section below gives more detail.
206 LPD command IPP operation
208 print-any-waiting-jobs ignore
210 receive-a-printer-job Print-Job or Create-Job/Send-Document
212 send queue state (short Get-Printer-Attributesand Get-Jobs
213 or long)
215 remove-jobs Cancel-Job
217 3.1 Print any waiting jobs
219 Command syntax:
221 print-waiting-jobs = %x01 printer-name LF
223 This command causes the LPD daemon check its queue and print any waiting
224 jobs. An IPP printer handles waiting jobs without such a nudge.
226 If the mapper receives this LPD command, it MUSTMUST ignore it and send
227 no IPP operation.
229 3.2 Receive a printer job
231 Command syntax:
233 receive-job = %x02 printer-name LF
235 The control file and data files mentioned in the following paragraphs
236 are received via LPD sub-commands that follow this command. Their
237 mapping to IPP commands and attributes is described later in this
238 section.
240 The mapper maps the 'Receive a printer job' command to either:
242 . the Print-Job operation which includes a single data file or
243 . the Create-Job operation followed by one Send-Document
244 operation for each data file.
246 If the IPP printer supports both Create-Job and Send-Document, and if a
247 job consists of:
249 . a single data file, the mapper SHOULD use the Print-Job
250 operation, but MAY use the Create-Job and Send-Document
251 operations.
252 . more than one data file, the mapper MUST use Create-Job
253 followed by one Send-Document for each received LPD data file.
255 If the IPP printer does not support both Create-Job and Send-Document,
256 and if a job consists of:
258 . a single data file, the mapper MUST use the PrintJob
259 operation.
260 . more than one data file, the mapper MUST submit each received
261 LPD data file as a separate Print-Job operation (thereby
262 converting a single LPD job into multiple IPP jobs).
264 If the mapper uses Create-Job and Send-Document, it MUST send the
265 Create-Job operation before it sends any Send-Document operations
266 whether the LPD control file, which supplies attributes for Create-Job,
267 arrives before or after all LPD data files.
269 NOTE: This specification does not specify how the mapper maps: the LPD
270 Printer-name operand to the IPP "printer-uri" parameter.
272 The following 3 sub-sections gives further details about the mapping
273 from LPD receive-a-printer-job sub-commands. Each of the following
274 sub-sections appear as sub-sections of section 6 of RFC 1179.
276 3.2.1 Abort job
278 Sub-command syntax:
280 abort-job = %x1 LF
282 This sub-command of receive-a-printer-job is intended to abort any job
283 transfer in process.
285 If the mapper receives this sub-command, it MUST cancel the job that it
286 is in the process of transmitting.
288 If the mapper is in the process of sending a Print-Job or Create-Job
289 operation, it terminates the job either by closing the connection, or
290 performing the Cancel-Job operation with the job-uri that it received
291 from the Print-Job or Create-Job operation.
293 NOTE: This sub-command is implied if at any time the connection between
294 the LPD client and server is terminated before an entire print job has
295 been transferred via an LPD Receive-a-printer-job request.
297 3.2.2 Receive control file
299 Sub-command syntax:
301 receive-control-file = %x2 number-of-bytes SP name-of-control-file LF
302 number-of-bytes = 1*DIGIT
303 name-of-control-file = "cfA" job-number client-host-name
304 ; e.g. "cfA123woden"
305 job-number = 3DIGIT
306 client-host-name =
308 This sub-command is roughly equivalent to the IPP Create-Job operation.
310 The mapper MUST use the contents of the received LPD control file to
311 create IPP parameter and attribute values to transmit with the Print-Job
312 or Create-Job operation.
314 3.2.3 Receive data file
316 Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file
318 receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
319 number-of-bytes = 1*DIGIT
320 name-of-data-file = "df" letter job-number client-host-name
321 ; e.g. "dfA123woden for the first file
322 letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z"
323 ; first file is "A",
324 ; second "B", and 52nd file is "z"
325 job-number = 3DIGIT
326 client-host-name =
328 This sub-command is roughly equivalent to the IPP Send-Document
329 operation.
331 The mapper MUST use the contents of the received LPD data file as the
332 data to transmit with the IPP Print-Job or Send-Document operation.
334 Although RFC-1179 alludes to a method for passing an unspecified
335 length data file by using an octet-count of zero, no implementations
336 support this feature.. The mapper MUST reject a job that has a value of
337 0 in the number-of-bytes field.
339 3.3 Send queue state (short)
341 Command syntax:
343 send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF
345 The mapper's response to this command includes information about the
346 printer and its jobs. RFC 1179 specifies neither the information nor the
347 format of its response. This document requires the mapper to follow
348 existing practice as specified in this document.
350 The mapper MUST produce a response in the following format which
351 consists of a printer-status line optionally followed by a heading line,
352 and a list of jobs. This format is defined by examples below. Appendix A
353 contains the ABNF syntax.
355 For an printer with no jobs, the response starts in column 1 and is:
357 no entries
359 For a printer with jobs, an example of the response is:
361 pinetree is ready and printing
362 Rank Owner Job Files Total Size
363 active fred 123 stuff 1204 bytes
364 1st smith 124 resume, foo 34576 bytes
365 2nd fred 125 more 99 bytes
366 3rd mary 126 mydoc 378 bytes
367 4th jones 127 statistics.ps 4567 bytes
368 5th fred 128 data.txt 9 bytes
370 The column numbers of above headings and job entries are:
372 | | | | |
373 01 08 19 35 63
375 The mapper MUST produce each field above from the following IPP
376 attribute:
378 LPD field IPP attribute special conversion details
380 printer- printer-state and For a printer-state of idle or
381 status printer-state-reasons processing, the mapper MUST use
382 the formats above. For stopped,
383 the mapper MUST use printer-state-
384 reasons to produce an unspecified
385 format for the error.
387 rank number-of- the mapper MUST the format above
388 intervening-jobs
390 owner job-originating-user- unspecified conversion; job-
391 name originating-user-name may be the
392 mapper's user-name
394 job job-id the mapper MUST use the job-id
396 files document-name the mapper MUST create a comma
397 separated list of the document-
398 names and then truncate this list
400 LPD field IPP attribute special conversion details
402 to the first 24 characters
404 total- job-k- the mapper MUST multiple the value
405 size octets*copies*1024 of job-k-octets by 1024 and by the
406 value of the "copies" attribute.
408 A mapper SHOULD use the job attribute number-of-intervening-jobs rather
409 than the job's position in a list of jobs to determine `rank' because a
410 Printer may omit jobs that it wants to keep secret. If a printer doesn't
411 support the job attribute number-of-intervening-jobs, a mapper MAY use
412 the job's position.
414 Note: a Printer may set the value of job-originating-user-name to the
415 authenticated user or to the value of "requesting-user-name", depending
416 on the implementation and configuration. For a gateway, the
417 authenticated user is the user-id of the gateway, but the "requesting-
418 user-name" may contain the name of the user who is the gateway's client.
420 In order to obtain the information specified above, The LPD-to-IPP
421 mapper MUST use the Get-Printer-Attributes operation to get printer-
422 status and SHOULD use the Get-Jobs operation to get information about
423 all of the jobs. If the LPD command contains job-numbers or user-names,
424 the mapper MAY handle the filtering of the response. If the LPD command
425 contains job-numbers but no user-names, the mapper MAY use Get-Job-
426 Attributes on each converted job-number rather than Get-Jobs. If the LPD
427 command contains a single user-name but no job-numbers, the mapper MAY
428 use Get-Jobs with the my-jobs option if the server supports this option
429 and if the server allows the client to be a proxy for the LPD user.
431 NOTE: This specification does not define how the mapper maps the LPD
432 Printer-name operand to the IPP "printer-uri" parameter.
434 3.4 Send queue state (long)
436 Command syntax:
438 send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF
440 The mapper's response to this command includes information about the
441 printer and its jobs. RFC 1179 specifies neither the information nor the
442 format of its response. This document requires the mapper to follow
443 existing practice as specified in this document.
445 The mapper MUST produce a response in the following format which
446 consists of a printer-status line optionally followed a list of jobs,
447 where each job consists of a blank line, a description line, and one
448 line for each file. The description line contains the user-name, rank,
449 job-number and host. This format is defined by examples below. Appendix
450 B contain the ABNF syntax.
452 For an printer with no jobs the response is:
454 no entries
456 For a printer with jobs, an example of the response is:
458 pinetree is ready and printing
460 fred: active [job 123 tiger]
461 2 copies of stuff 602 bytes
463 smith: 1st [job 124 snail]
464 2 copies of resume 7088 bytes
465 2 copies of foo 10200 bytes
467 fred: 2nd [job 125 tiger]
468 more 99 bytes
470 The column numbers of above headings and job entries are:
472 | | |
473 01 09 41
475 Although the format of the long form is different from the format of the
476 short form, their fields are identical except for a) the copies and host
477 fields which are only in the long form, and b) the "size" field
478 contains the single copy size of each file. Thus the sum of the file
479 sizes in the "size" field times the value of the "copies" field
480 produces the value for the "Total Size" field in the short form. For
481 fields other than the host and copies fields, see the preceding section.
482 For the host field see the table below.
484 LPD field IPP attribute special conversion details
486 host unspecified conversion; job-
487 originating-host may be the
488 mapper's host
490 copies copies the mapper MUST assume the value
491 of copies precedes the string
492 "copies of "; otherwise, the
493 value of copies is 1.
495 NOTE: This specification does not define how the mapper maps the LPD
496 Printer-name operand to the IPP printer-uri parameter.
498 3.5 Remove jobs
500 Command syntax:
502 remove-jobs = %x05 printer-name SP agent
503 *(SP(user-name / job-number)) LF
505 The agent operand is the user-name of the user initiating the remove-
506 jobs command. The special user-name 'root' indicates a privileged user
507 who can remove jobs whose user-name differs from the agent..
509 The mapper MUST issue one Cancel-Job operation for each job referenced
510 by the remove-jobs command. Each job-number in the remove-jobs command
511 references a single job. Each user-name in the remove-jobs command
512 implicitly references all jobs owned by the specified user. The active
513 job is implicitly referenced when the remove-jobs command contains
514 neither job-numbers nor user-names. The mapper MAY use Get-Jobs to
515 determine the job-uri of implicitly referenced jobs.
517 The mapper MUST not use the agent name of `root' when end-users cancel
518 their own jobs. Violation of this rule creates a potential security
519 violation, and it may cause the printer to issue a notification that
520 misleads a user into thinking that some other person canceled the job.
522 If the agent of a remove-jobs command for a job J is the same as the
523 user name specified with the `P' function in the control file for job J,
524 then the mapper MUST ensure that the caller of the Cancel-Job command
525 for job J is the same as job-originating-user for job J.
527 Note: This requirement means that a mapper must be consistent in who the
528 receiver perceives as the caller of IPP operations. The mapper either
529 acts as itself or acts on behalf of another user. The latter is
530 preferable if it is possible. This consistency is necessary between
531 Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but
532 it is also desirable for other operations. For example, Get-Jobs may
533 give more information about job submitted by the caller of this
534 operation.
536 NOTE: This specification does not define how the mapper maps: (1) the
537 LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to
538 the IPP "job-uri".
540 NOTE: This specification does not specify how the mapper maps the LPD
541 user-name to the IPP job-originating-user because the mapper may use its
542 own user-name with jobs.
544 4. Mapping of LPD Control File Lines to IPP Parameters
546 This section describes the mapping from LPD control file lines (called
547 `functions') to IPP operation input parameters. The mapper receives the
548 control file lines via the LPD receive-control-file sub-command.. Each
549 of the LPD functions appear as sub-sections of section 7 of RFC 1179.
551 In LPD control file lines, the text operands have a maximum length of 31
552 or 99 while IPP input parameters have a maximum of 255 characters.
553 Therefore, no data is lost.
555 The mapper converts each supported LPD function to its corresponding IPP
556 parameter as defined by tables in the subsections that follow. These
557 subsections group functions according to whether they are:
559 . required with a job,
560 . optional with a job
561 . required with each document.
563 In the tables below, each LPD value is given a name, such as `h'. If an
564 IPP value uses the LPD value, then the IPP value column contains the LPD
565 name, such as `h' to denote this. Otherwise, the IPP value column
566 specifies the literal value.
568 4.1 Required Job Functions
570 The following LPD functions MUST be in a received LPD job. The mapper
571 MUST receive each of the following LPD functions and MUST include the
572 information as a parameter with each IPP job. The functions SHOULD be in
573 the order `H', `P' and they SHOULD be the first two functions in the
574 control file, but they MAY be anywhere in the control file and in any
575 order.
577 LPD function IPP
579 name value description name value
581 H h Originating Host h (in security layer)
583 P u User identification requesting- u (and in security
584 user-name layer)
586 none ipp- `true'
587 attribute-
588 fidelity
590 A mapper MAY sends its own host rather than the client's host, and a
591 mapper MAY send its own user-name as user identification rather than the
592 client user. But in any case, the values sent MUST be compatible with
593 the Cancel-Job operation. The IPP operation MAY have no way to specify
594 an originating host-name.
596 The mapper MUST include ipp-attribute-fidelity =true so that it doesn't
597 have to determine which attributes a printer supports.
599 4.2 Optional Job Functions
601 The following LPD functions MAY be in a received job. These function
602 SHOULD follow the required job functions and precede the document
603 functions, but they MAY be anywhere in the control file.
605 If the mapper receives such an LPD function, the mapper MUST include the
606 corresponding IPP attribute with the value converted as specified in the
607 table below. If the mapper does not receive such an LPD attribute, the
608 mapper MUST NOT include the corresponding IPP attribute, except the `L'
609 LPD function whose absence has a special meaning as noted in the table.
611 LPD function IPP
613 name value description name value
615 J j Job name for job-name j
616 banner page
618 L l Print banner page job-sheets `standard' if `L' is
619 present
621 `none' if `L' is present
623 M m Mail When Printed IPP has no notification
624 mechanism. To support
625 this LPD feature, the
626 gateway must poll
628 4.3 Required Document Functions
630 The mapper MUST receive one set of the required document functions with
631 each copy of a document, and MUST include the converted information as
632 parameters with each IPP document
634 If the control file contains required and recommended document
635 functions, the required functions SHOULD precede the recommended ones
636 and if the job contains multiple documents, all the functions for each
637 document are grouped together as shown in the example of section 6.3
638 "Required Document Functions". However, the document functions MAY be in
639 any order.
641 LPD function IPP
643 name value description name value
645 f fff Print formatted document-format 'application/octet-
646 file stream'
648 l fff Print file leaving document-format 'application/octet-
649 control characters stream'
651 o fff Print Postscript document-format 'application/
652 output file PostScript'
654 copies see note
656 Note: In practice, the `f' LPD function is often overloaded. It is often
657 used with any format of document data including PostScript and PCL data.
659 Note: In practice, the `l' LPD function is often used as a rough
660 equivalent to the `f' function.
662 Note: When RFC 1179 was written, no implementation supported the `o'
663 function; instead `f' was used for PostScript. Windows NT now sends `o'
664 function for a PostScript file.
666 Note: the value `fff' of the `f', `l' and `o' functions is the name of
667 the data file as transferred, e.g. "dfA123woden".
669 If the mapper receives any other lower case letter, the mapper MUST
670 reject the job because the document contains a format that the mapper
671 does not support.
673 The mapper determines the number of copies by counting the number of
674 occurrences of each `fff' file with one of the lower-case functions
675 above. For example, if `f dfA123woden' occurs 4 times, then copies has a
676 value of 4. Although the LPD protocol allows the value of copies to be
677 different for each document, the commands and the receiving print
678 systems don't support this.
680 4.4 Recommended Document Functions
682 The mapper SHOULD receive one set of the recommended document functions
683 with each document, and SHOULD include the converted information as
684 parameters with each IPP document. The functions SHOULD be received in
685 the order `U' and `N', but they MAY arrive in any order.
687 LPD function IPP
689 name value description name value
691 U fff ignored
693 N n Name of source file document-name n
695 Note: the value `fff' of the `U' function is the name of the data file
696 as transferred, e.g. "dfA123woden".
698 5. Mapping from IPP operations to LPD commands
700 If the IPP-to-LPD mapper receives an IPP operation, the following table
701 summarizes the LPD command that it uses. Each section below gives the
702 detail. Each of the following sub-sections appear as sub-sections of
703 section 3 in the document "Internet Printing Protocol/1.0: Model and
704 Semantics" [ipp-mod].
706 IPP operation LPD command
708 Print-Job or Print-URI or receive-a-printer-job
709 Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs
711 Validate-Job implemented by the mapper
713 Cancel-Job remove-jobs
715 Get-Printer-Attributes, Get-Job- send queue state (short or long)
716 Attributes or Get-Jobs
718 5.1 Print-Job
720 The mapper MUST send the following commands in the order listed below:
722 . receive-a-printer-job command
723 . both receive-control-file sub-command and receive-data-file
724 sub-command
725 (unspecified order, see Note below)
726 . print-any-waiting-jobs command,
727 except that if the mapper is sending a sequence of receive-a-
728 printer-job commands, it MAY omit sending print-any-waiting-
729 jobs after any receive-a printer-job command that is neither
730 the first nor last command in this sequence
732 Note: it is recommended that the order of the receive-control-file sub-
733 command and the receive-data-file sub-command be configurable because
734 either order fails for some print systems. Some print systems assume
735 that the control file follows all data files and start printing
736 immediately on receipt of the control file. When such a print system
737 tries to print a data file that has not arrived, it produces an error.
738 Other print systems assume that the control file arrives before the data
739 files and start printing when the first data file arrives. Such a system
740 ignores the control information, such as banner page or copies.
742 NOTE: This specification does not define the mapping between the IPP
743 printer-uri and the LPD printer-name.
745 The mapper MUST send the IPP parameters and attributes received from the
746 operation to the LPD printer by using the LPD receive-control-file sub-
747 command. The mapper MUST create the LPD job-number for use in the
748 control file name, but the receiving printer MAY, in some circumstances,
749 assign a different job-number to the job. The mapper MUST create the IPP
750 job-id and IPP job-uri returned in the Print-Job response.
752 NOTE: This specification does not specify how the mapper determines the
753 LPD job-number, the IPP job-id or the IPP job-uri of a job that it
754 creates nor does it specify the relation ship between the IPP job-uri,
755 IPP the job-id and the LPD job-number, both of which the mapper creates.
756 However, it is likely that the mapper will use the same integer value
757 for both theLPD job-number and the IPP job-id, and that the IPP Job-uri
758 is the printer's URI with the job-id concatenated on the end.
760 The mapper MUST send data received in the IPP operation to the LPD
761 printer by using the LPD receive-data-file sub-command. The mapper MUST
762 specify the exact number of bytes being transmitted in the number-of-
763 bytes field of the receive-data-file sub-command. It MUST NOT use a
764 value of 0 in this field.
766 If the mapper, while it is transmitting a receive-a-printer-job command
767 or sub-command, either detects that its IPP connection has closed or
768 receives a Cancel-Job operation, the mapper MUST terminate the LPD job
769 either with the abort sub-command or the remove-jobs command.
771 Error code conversion is not specified in this document..
773 5.2 Print-URI
775 The mapper MUST handle this operation in the same way as a Print-Job
776 operation except that it MUST obtain data referenced by the "document-
777 uri" parameter and MUST then treat that data as if it had been received
778 via a Print-Job operation.
780 5.3 Validate-Job
782 The mapper MUST perform this operation directly. Because LPD supports
783 very few attributes, this operation doesn't have much to check.
785 5.4 Create-Job
787 The mapper MUST handle this operation like Print-Job, except
789 . the mapper MUST send the control file after it has received
790 the last Send-Document or Send-URI operation because the
791 control file contains all the document-name and document-
792 format values specified in the Send-Document and Send-URI
793 operations.
794 . the mapper MUST perform one receive-data-file sub-command for
795 each Send-Document or Send-URI operation received and in the
796 same order received.
797 . the mapper MUST send the control file either before all data
798 files or after all data files.
799 (See the note in the section on Print-Job about the dilemma of
800 sending the control file either before or after the data
801 files.
803 5.5 Send-Document
805 The mapper performs a receive-data-file sub-command on the received
806 data. See the preceding section 5.4 "Create-Job" for the details.
808 5.6 Send-URI
810 The mapper MUST obtain the data referenced by the "document-uri"
811 parameter, and MUST then treat that data as if it had been received via
812 a Send-Document operation. See the preceding section 5.5 "Send-Document"
813 for the details.
815 5.7 Cancel-Job
817 The mapper MUST perform a remove-jobs command with the following
818 parameters:
820 . the printer is the one to which the job was submitted, that is
821 the IPP printer-uri is mapped to an LPD printer-name by the
822 same mechanism as for all commands.
823 . the agent is the authenticated user-name of the IPP client,
824 . the job-number is the job-id returned by the Print-Job
825 command, that is, the LPD job-number has the same value as the
826 IPP job-id for likely implementations.
828 5.8 Get-Printer-Attributes
830 LPD severely limits the set of attributes that the mapper is able to
831 return in its response for this operation. The mapper MUST support, at
832 most, the following printer attributes:
834 . printer-state
835 . printer-state-reasons
837 The mapper uses either the long or short form of the "send queue state"
838 command.
840 The mapper MUST assume that the LPD response that it receives has the
841 format and information specified in section 3.3 "Send queue state
842 (short)" and section 3.4 "Send queue state (long)". The mapper MUST
843 determine the value of each requested attribute by using the inverse of
844 the mapping specified in the two aforementioned sections.
846 Note: the mapper can determine the response from the printer-status line
847 without examining the rest of the LPD response.
849 5.9 Get-Job-Attributes
851 LPD severely limits the set of attributes that the mapper is able to
852 return in its response for this operation. The mapper MUST support, at
853 most, the following job attributes:
855 . number-of-intervening-jobs
856 . job-originating-user-name
857 . job-id
858 . document-name
859 . job-k-octets
860 . copies
862 The mapper uses either the long or short form of the "send queue state"
863 command. If it receives a request for the "job-k-octets" or "copies"
864 and supports the attribute it MUST use the long form; otherwise, it MUST
865 use the short form.
867 Note: the value of job-k-octets is the value in the short form divided
868 by the number of "copies" which is on the long form only. Its value can
869 also be determined by adding the "size" field values for each document
870 in the job in the long form.
872 The mapper MUST assume that the LPD response that it receives has the
873 format and information specified in section 3.3 "Send queue state
874 (short)" and section 3.4 "Send queue state (long)". The mapper MUST
875 determine the value of each requested attribute by using the inverse of
876 the mapping specified in the two aforementioned sections.
878 Note: when the mapper uses the LPD short form, it can determine the
879 response from the single LPD line that pertains to the job specified by
880 the Get-Job-Attributes operation.
882 NOTE: the mapper can use its correspondence between the IPP job-id, job-
883 uri and the LPD job-number.
885 5.10 Get-Jobs
887 The mapper MUST perform this operation in the same way as Get-Job-
888 Attributes except that the mapper converts all the LPD job-lines, and
889 the IPP response contains one job object for each job-line in the LPD
890 response..
892 6. Mapping of IPP Parameters to LPD Control File Lines
894 This section describes the mapping from IPP operation input parameters
895 to LPD control file lines (called `functions'). The mapper receives the
896 IPP operation input parameters via the IPP operation. Each of the IPP
897 operation input parameters appear as sub-sections of section 3 and 4.2
898 in the IPP model document [ipp-mod].
900 In the context of LPD control file lines, the text operands have a
901 maximum length of 31 or 99 while IPP input parameters have a maximum of
902 255 characters. Therefore, there may be some data loss if the IPP
903 parameters exceed the maximum length of the LPD equivalent operands.
905 The mapper converts each supported IPP parameter to its corresponding
906 LPD function as defined by tables in the subsections that follow. These
907 subsections group functions according to whether they are:
909 . required with a job,
910 . optional with a job
911 . required with each document.
913 In the tables below, each IPP value is given a name, such as `h'. If an
914 LPD value uses the IPP value, then the LPD value column contains the IPP
915 name, such as `h' to denote this. Otherwise, the LPD value column
916 specifies the literal value.
918 6.1 Required Job Functions
920 The mapper MUST include the following LPD functions with each job, and
921 they MUST have the specified value. They MUST be the first functions in
922 the control file and they MUST be in the order "H" and then "P".
924 IPP LPD function
926 name value name value description
928 (perhaps in security h H gateway host Originating Host
929 layer)
931 requesting-user-name u P u User identification
932 and in the security
933 layer
935 A mapper MUST sends its own host rather than the client's host, because
936 some LPD systems require that it be the same as the host from which the
937 remove-jobs command comes. A mapper MAY send its own user name as user
938 identification rather than the client user. But in any case, the values
939 sent MUST be compatible with the LPD remove-jobs operation.
941 6.2 Optional Job Functions
943 The mapper MAY include the following LPD functions with each job. They
944 MUST have the specified value if they are sent. These functions, if
945 present, MUST follow the require job functions, and they MUST precede
946 the required document functions.
948 IPP attribute LPD function
950 name value name value description
952 job-name j J j Job name for banner
953 page
955 job-sheets `standard' L u Print banner page
957 job-sheets `none' omit `L' function
959 Note: `L' has special meaning when it is omitted. If `J' is omitted,
960 some undefined behavior occurs with respect to the banner page.
962 6.3 Required Document Functions
964 The mapper MUST include one set of the following LPD functions with
965 each document, and they MUST have the specified values. For each
966 document, the order of the functions MUST be `f', `U' and then `N',
967 where `f' is replicated once for each copy.
969 IPP attribute LPD function
971 name value name value description
973 document- 'application/octet- f fff Print formatted file
974 format stream' or
975 'application/PostScript'
977 copies c replicate `f' `c'
978 times
980 none U fff Unlink data file
982 document- n N n Name of source file
983 name
985 Note: the value `fff' of the `f' and `U' functions is the name of the
986 data file as transferred, e.g. "dfA123woden".
988 Note: the mapper MUST NOT send the `o' function
990 ISSUE: should we register DVI, troff or ditroff?
992 If the mapper receives no "ipp-attribute-fidelitybest-effort" or it has
993 a value of false, then the mapper MUST reject the job if it specifies
994 attributes or attribute values that are not among those supported in the
995 above tables.
997 Below is an example of the minimal control file for a job with three
998 copies of two files `foo' and `bar':
1000 H tiger
1001 P jones
1002 f dfA123woden
1003 f dfA123woden
1004 f dfA123woden
1005 U dfA123woden
1006 N foo
1007 f dfB123woden
1008 f dfB123woden
1009 f dfB123woden
1010 U dfB123woden
1011 N bar
1013 7. Security Considerations
1015 There are no security issues beyond those covered in the IPP Encoding
1016 and Transport document [ipp-pro], the IPP model document [ipp-mod] and
1017 the LPD document [rfc1179].
1019 8. References
1021 [ipp-lpd] Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping
1022 between LPD and IPP Protocols", draft-ietf-ipp-lpd-ipp-map-
1023 04.txt, June 1998.
1025 [ipp-mod] Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell,
1026 P., "Internet Printing Protocol/1.0: Model and Semantics" draft-
1027 ietf-ipp-mod-10.txt, June, 1998.
1029 [ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet
1030 Printing Protocol/1.0: Encoding and Transport", draft-ietf-ipp-
1031 pro-06.txt, June, 1998.
1033 [ipp-rat] Zilles, S., "Rationale for the Structure and Model and
1034 Protocol for the Internet Printing Protocol", draft-ietf-ipp-
1035 rat-03.txt, June, 1998.
1037 [ipp-req] Wright, D., "Design Goals for an Internet Printing
1038 Protocol", draft-ietf-ipp-req-02.txt, June, 1998.
1040 [rfc1179] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179,
1041 August 1990.
1043 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and
1044 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
1046 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate
1047 Requirement Levels", RFC 2119 , March 1997
1049 [abnf] D. Crocker et al., "Augmented BNF for Syntax Specifications:
1050 ABNF", draft-ietf-drums-abnf-05.txt.
1052 9. Author's Addresses
1054 Robert Herriot (editor) Norm Jacobs
1055 Sun Microsystems Inc. Sun Microsystems Inc.
1056 901 San Antonio.Road., MPK-17 1430 Owl Ridge Rd.
1057 Mountain View, CA 94043 Colorado Springs, CO 80919
1059 Phone: 650-786-8995 Phone: 719-532-9927
1060 Fax: 650-786-7077 Fax: 719-535-0956
1061 Email: robert.herriot@eng.sun.com Email:
1062 Norm.Jacobs@Central.sun.com
1064 Thomas N. Hastings Jay Martin
1065 Xerox Corporation Underscore, Inc.
1066 701 S. Aviation Blvd., ESAE-231 41-C Sagamore Park Road
1067 El Segundo, CA 90245 Hudson, NH 03051-4915
1069 Phone: 310-333-6413 Phone: 603-889-7000
1070 Fax: 310-333-5514 Fax: 603-889-2699
1071 EMail: hastings@cp10.es.xerox.com Email: jkm@underscore.com
1073 10. Appendix A: ABNF Syntax for response of Send-queue-state (short)
1075 The syntax in ABNF for the response to the LPD command `send-queue-state
1076 (long)' is:
1078 status-response = empty-queue / nonempty-queue
1079 empty-queue = "no-entries" LF
1080 nonempty-queue = printer-status LF heading LF *(job LF)
1081 printer-status = OK-status / error-status
1082 OK-status = printer-name SP "ready and printing" LF
1083 error-status = < implementation dependent status information >
1084 heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files"
1085 23SP "Total Size" LF
1086 ; the column headings and their values below begin
1087 at the columns
1088 ; 1, 8, 19, 35 and 63
1089 job = rank *SP owner *SP job *SP files *SP total-size "bytes"
1090 ; jobs are in order of oldest to newest
1091 rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1092 ; job that is printing is "active"
1093 ; other values show position in the queue
1094 owner =
1095 job = 1*3DIGIT ; job-number
1096 files = *( "," ) ; truncated to 24 characters
1097 total-size = 1*DIGIT ; combined size in bytes of all documents
1099 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)
1101 The syntax in ABNF for the response to the LPD command `send-queue-state
1102 (long)' is:
1104 status-response = empty-queue / nonempty-queue
1105 empty-queue = "no-entries" LF
1106 nonempty-queue = printer-status LF *job
1107 printer-status = OK-status / error-status
1108 OK-status = printer-name SP "ready and printing" LF
1109 error-status = < implementation dependent status information >
1110 job = LF line-1 LF line-2 LF
1111 line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
1112 line-2 = file-name 1*SP document-size "bytes"
1113 ; jobs are in order of oldest to newest
1114 rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
1115 ; job that is printing is "active"
1116 ; other values show position in the queue
1117 owner =
1118 job = 1*3DIGIT
1119 file-name = [ 1*DIGIT "copies of" SP ]
1120 ; truncated to 24 characters
1121 document-size = 1*DIGIT ;size of single copy of the document.
1123 12. Appendix C: Unsupported LPD functions
1125 The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper
1126 ignores them and the IPP-to-LPD mapper does not send them.
1128 LPD command
1130 name description
1132 C Class for banner page
1134 I Indent Printing
1136 H Host of client
1138 M Mail when printed
1140 S Symbolic link data
1142 T Title for pr
1144 W Width of output
1146 1 troff R font
1148 2 troff I font
1150 3 troff B font
1152 4 troff S font
1154 The follow LPD functions specify document-formats which have no IPP
1155 equivalent, unless someone registers them. The LPD-to-IPP mapper rejects
1156 jobs that request such a document format, and the IPP-to-LPD mapper does
1157 not send them.
1159 LPD command
1161 name description
1163 c Plot CIF file
1165 d Print DVI file
1167 g Plot file
1169 k reserved for Kerberized clients and servers
1170 LPD command
1172 name description
1174 n Print ditroff output file
1176 p Print file with 'pr' format
1178 r File to print with FORTRAN carriage control
1180 t Print troff output file
1182 v Print raster file
1184 z reserved for future use with the Palladium
1185 print system
1187 13. Appendix D: Full Copyright Statement
1189 Copyright (C)The Internet Society (1997). All Rights Reserved
1191 This document and translations of it may be copied and furnished to
1192 others, and derivative works that comment on or otherwise explain it or
1193 assist in its implementation may be prepared, copied, published and
1194 distributed, in whole or in part, without restriction of any kind,
1195 provided that the above copyright notice and this paragraph are included
1196 on all such copies and derivative works. However, this document itself
1197 may not be modified in any way, such as by removing the copyright notice
1198 or references to the Internet Society or other Internet organizations,
1199 except as needed for the purpose of developing Internet standards in
1200 which case the procedures for copyrights defined in the Internet
1201 Standards process must be followed, or as required to translate it into
1202 languages other than English.
1204 The limited permissions granted above are perpetual and will not be
1205 revoked by the Internet Society or its successors or assigns.
1207 This document and the information contained herein is provided on an "AS
1208 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
1209 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
1210 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
1211 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
1212 FITNESS FOR A PARTICULAR PURPOSE.