INTERNET-DRAFT Robert Herriot (editor) Sun Microsystems, Inc. draft-ietf-ipp-lpd-ipp-map-04.txt Tom Hastings Xerox Corporation Norm Jacobs Sun Microsystems, Inc. Jay Martin Underscore, Inc. June 23, 1997 Mapping between LPD and IPP Protocols Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C)The Internet Society (1997). All Rights Reserved. Abstract This Internet-Draft specifies the mapping between (1) the commands and operands of the "Line Printer Daemon (LPD) Protocol" specified in RFC 1179 and (2) the operations and parameters of the Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. This document is an informational document that is not on the standards track. It is intended to help implementors of gateways between IPP and LPD. It also provides an example, which gives additional insight into IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, it fell short in some areas. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the Herriot, Hastings, June 23, 1998, [Page 1] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 numerous divergent extensions to the LPD protocol that have been made by many implementers. Herriot, Hastings, June 23, 1998, [Page 2] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 TABLE OF CONTENTS 1. Introduction........................................................4 2. Terminology.........................................................4 3. Mapping from LPD Commands to IPP Operations.........................5 3.1 Print any waiting jobs...........................................5 3.2 Receive a printer job............................................5 3.2.1 Abort job....................................................6 3.2.2 Receive control file.........................................7 3.2.3 Receive data file............................................7 3.3 Send queue state (short).........................................7 3.4 Send queue state (long)..........................................9 3.5 Remove jobs.....................................................10 4. Mapping of LPD Control File Lines to IPP Parameters................11 4.1 Required Job Functions..........................................12 4.2 Optional Job Functions..........................................12 4.3 Required Document Functions.....................................13 4.4 Recommended Document Functions..................................14 5. Mapping from IPP operations to LPD commands........................14 5.1 Print-Job.......................................................14 5.2 Print-URI.......................................................16 5.3 Validate-Job....................................................16 5.4 Create-Job......................................................16 5.5 Send-Document...................................................16 5.6 Send-URI........................................................16 5.7 Cancel-Job......................................................16 5.8 Get-Printer-Attributes..........................................17 5.9 Get-Job-Attributes..............................................17 5.10 Get-Jobs.......................................................18 6. Mapping of IPP Parameters to LPD Control File Lines................18 6.1 Required Job Functions..........................................19 6.2 Optional Job Functions..........................................19 6.3 Required Document Functions.....................................19 7. Security...........................................................20 8. References.........................................................20 9. Author's Addresses.................................................21 10. Appendix A: ABNF Syntax for response of Send-queue-state (short)..21 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)...22 12. Appendix C: Unsupported LPD functions.............................22 13. Appendix D: Full Copyright Statement..............................23 Herriot, Hastings, June 23, 1998, [Page 3] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 1 Mapping between the LPD and IPP Protocols 2 1. Introduction 3 The reader of this specification is expected to be familiar with the IPP 4 Model and Semantics specification [ipp-mod], the IPP Encoding and 5 transport [ipp-enc], and the Line Printer Daemon (LPD) protocol 6 specification [rfc1179] as described in RFC 1179. 7 RFC 1179 was written in 1990 in an attempt to document existing LPD 8 protocol implementations. Since then, a number of undocumented 9 extensions have been made by vendors to support functionality specific 10 to their printing solutions. All of these extensions consist of 11 additional control file commands. This document does not address any of 12 these vendor extensions. Rather it addresses existing practice within 13 the context of the features described by RFC 1179. Deviations of 14 existing practice from RFC 1179 are so indicated. 15 Other LPD control file commands in RFC 1179 are obsolete. They are 16 intended to work on "text" only formats and are inappropriate for many 17 contemporary document formats that completely specify each page. This 18 document does not address the support of these obsolete features. 19 In the area of document formats, also known as page description 20 languages (PDL), RFC 1179 defines a fixed set with no capability for 21 extension. Consequently, some new PDL.s are not supported, and some of 22 those that are supported are sufficiently unimportant now that they have 23 not been registered for use with the Printer MIB[rfc1759] and IPP[ipp- 24 mod] [ipp-enc], though they could be registered if desired. See the 25 Printer MIB specification [rfc1759] and/or the IPP Model specification 26 [ipp-mod] for instructions for registration of document-formats with 27 IANA. IANA lists the registered document-formats as "printer 28 languages". 29 This document addresses the protocol mapping for both directions: 30 mapping of the LPD protocol to the IPP protocol and mapping of the IPP 31 protocol to the LPD protocol. The former is called the .LPD-to-IPP 32 mapper. and the latter is called the .IPP-to-LPD mapper.. 33 This document is an informational document that is not on the standards 34 track. It is intended to help implementors of gateways between IPP and 35 LPD. It also provides an example, which gives additional insight into 36 IPP. 37 2. Terminology 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [abnf]. Herriot, Hastings, June 23, 1998, [Page 4] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 41 RFC 1179 uses the word .command. in two contexts: for over-the-wire 42 operations and for command file functions. This document SHALL use the 43 word .command. for the former and the phrase .functions. for the latter. 44 The syntax of the LPD commands is given using ABNF [abnf]. 45 The following tokens are used in order to make the syntax more readable: 46 LF stands for %x0A (linefeed) 47 SP stands for %x20. (space) 48 DIGIT stands for %x30-39 (.0. to .9.) 49 3. Mapping from LPD Commands to IPP Operations 50 This section describes the mapping from LPD commands to IPP operations. 51 Each of the following sub-sections appear as sub-sections of section 5 52 of RFC 1179. 53 The following table summarizes the IPP operation that the mapper uses 54 when it receives an LPD command. Each section below gives more detail. LPD command IPP operation print-any-waiting-jobs ignore receive-a-printer-job Print-Job or Create-Job/Send-Document send queue state (short Get-Printer-Attributesand Get-Jobs or long) remove-jobs Cancel-Job 55 3.1 Print any waiting jobs 56 Command syntax: 57 print-waiting-jobs = %x01 printer-name LF 58 This command causes the LPD daemon check its queue and print any waiting 59 jobs. An IPP printer handles waiting jobs without such a nudge. 60 If the mapper receives this LPD command, it SHALL ignore it and send no 61 IPP operation. 62 3.2 Receive a printer job 63 Command syntax: 64 receive-job = %x02 printer-name LF 65 The control file and data files mentioned in the following paragraphs 66 are received via LPD sub-commands that follow this command. Their 67 mapping to IPP commands and attributes is described later in this 68 section. 69 The mapper maps the 'Receive a printer job' command to either: Herriot, Hastings, June 23, 1998, [Page 5] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 70 @ the Print-Job operation which includes a single data file or 71 @ the Create-Job operation followed by one Send-Document 72 operation for each data file. 73 If the IPP printer supports both Create-Job and Send-Document, and if a 74 job consists of: 75 @ a single data file, the mapper SHOULD use the Print-Job 76 operation, but MAY use the Create-Job and Send-Document 77 operations. 78 @ more than one data file, the mapper SHALL use Create-Job 79 followed by one Send-Document for each received LPD data file. 80 If the IPP printer does not support both Create-Job and Send-Document, 81 and if a job consists of: 82 @ a single data file, the mapper SHALL use the PrintJob 83 operation. 84 @ more than one data file, the mapper SHALL submit each received 85 LPD data file as a separate Print-Job operation (thereby 86 converting a single LPD job into multiple IPP jobs). 87 If the mapper uses Create-Job and Send-Document, it MUST send the 88 Create-Job operation before it sends any Send-Document operations 89 whether the LPD control file, which supplies attributes for Create-Job, 90 arrives before or after all LPD data files. 91 NOTE: This specification does not specify how the mapper maps: the LPD 92 Printer-name operand to the IPP "printer-uri" parameter. 93 The following 3 sub-sections gives further details about the mapping 94 from LPD receive-a-printer-job sub-commands. Each of the following 95 sub-sections appear as sub-sections of section 6 of RFC 1179. 96 3.2.1 Abort job 97 Sub-command syntax: 98 abort-job = %x1 LF 99 This sub-command of receive-a-printer-job is intended to abort any job 100 transfer in process. 101 If the mapper receives this sub-command, it SHALL cancel the job that it 102 is in the process of transmitting. 103 If the mapper is in the process of sending a Print-Job or Create-Job 104 operation, it terminates the job either by closing the connection, or 105 performing the Cancel-Job operation with the job-uri that it received 106 from the Print-Job or Create-Job operation. Herriot, Hastings, June 23, 1998, [Page 6] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 107 NOTE: This sub-command is implied if at any time the connection between 108 the LPD client and server is terminated before an entire print job has 109 been transferred via an LPD Receive-a-printer-job request. 110 3.2.2 Receive control file 111 Sub-command syntax: 112 receive-control-file = %x2 number-of-bytes SP name-of-control-file LF 113 number-of-bytes = 1*DIGIT 114 name-of-control-file = .cfA. job-number client-host-name 115 ; e.g. .cfA123woden. 116 job-number = 3DIGIT 117 client-host-name = 118 This sub-command is roughly equivalent to the IPP Create-Job operation. 119 The mapper SHALL use the contents of the received LPD control file to 120 create IPP parameter and attribute values to transmit with the Print-Job 121 or Create-Job operation. 122 3.2.3 Receive data file 123 Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file 124 receive-data-file = %x03 number-of-bytes SP name-of-data-file LF 125 number-of-bytes = 1*DIGIT 126 name-of-data-file = .df. letter job-number client-host-name 127 ; e.g. .dfA123woden for the first file 128 letter = %x41-5A / %x61-7A ; .A. to .Z., .a. to .z. 129 ; first file is .A., 130 ; second .B., and 52nd file is .z. 131 job-number = 3DIGIT 132 client-host-name = 133 This sub-command is roughly equivalent to the IPP Send-Document 134 operation. 135 The mapper SHALL use the contents of the received LPD data file as the 136 data to transmit with the IPP Print-Job or Send-Document operation. 137 Although RFC-1179 alludes to a method for passing an unspecified 138 length data file by using an octet-count of zero, no implementations 139 support this feature.. The mapper SHALL reject a job that has a value of 140 0 in the number-of-bytes field. 141 3.3 Send queue state (short) 142 Command syntax: Herriot, Hastings, June 23, 1998, [Page 7] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 143 send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF 144 The mapper.s response to this command includes information about the 145 printer and its jobs. RFC 1179 specifies neither the information nor the 146 format of its response. This document requires the mapper to follow 147 existing practice as specified in this document. 148 The mapper SHALL produce a response in the following format which 149 consists of a printer-status line optionally followed by a heading line, 150 and a list of jobs. This format is defined by examples below. Appendix A 151 contains the ABNF syntax. 152 For an printer with no jobs, the response starts in column 1 and is: 153 no entries 154 For a printer with jobs, an example of the response is: 155 killtree is ready and printing 156 Rank Owner Job Files Total Size 157 active fred 123 stuff 1204 bytes 158 1st smith 124 resume, foo 34576 bytes 159 2nd fred 125 more 99 bytes 160 3rd mary 126 mydoc 378 bytes 161 4th jones 127 statistics.ps 4567 bytes 162 5th fred 128 data.txt 9 bytes 163 164 The column numbers of above headings and job entries are: 165 166 | | | | | 167 01 08 19 35 63 168 169 The mapper SHALL produce each field above from the following IPP 170 attribute: LPD field IPP attribute special conversion details printer- printer-state and For a printer-state of idle or status printer-state-reasons processing, the mapper SHALL use the formats above. For stopped, the mapper SHALL use printer- state-reasons to produce an unspecified format for the error. rank number-of- the mapper SHALL the format above intervening-jobs owner job-originating-user- unspecified conversion; job- name originating-user-name may be the mapper.s user-name job job-id the mapper shall use the job-id files document-name the mapper shall create a comma separated list of the document- names and then truncate this list to the first 24 characters total- job-k- the mapper shall multiple the Herriot, Hastings, June 23, 1998, [Page 8] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 size octets*copies*1024 value of job-k-octets by 1024 and by the value of the .copies. attribute. 171 172 A mapper SHOULD use the job attribute number-of-intervening-jobs rather 173 than the job.s position in a list of jobs to determine .rank. because a 174 Printer may omit jobs that it wants to keep secret. If a printer doesn.t 175 support the job attribute number-of-intervening-jobs, a mapper MAY use 176 the job.s position. 177 Note: a Printer may set the value of job-originating-user-name to the 178 authenticated user or to the value of .requesting-user-name., depending 179 on the implementation and configuration. For a gateway, the 180 authenticated user is the user-id of the gateway, but the .requesting- 181 user-name. may contain the name of the user who is the gateway.s client. 182 In order to obtain the information specified above, The LPD-to-IPP 183 mapper SHALL use the Get-Printer-Attributes operation to get printer- 184 status and SHOULD use the Get-Jobs operation to get information about 185 all of the jobs. If the LPD command contains job-numbers or user-names, 186 the mapper MAY handle the filtering of the response. If the LPD command 187 contains job-numbers but no user-names, the mapper MAY use Get-Job- 188 Attributes on each converted job-number rather than Get-Jobs. If the LPD 189 command contains a single user-name but no job-numbers, the mapper MAY 190 use Get-Jobs with the my-jobs option if the server supports this option 191 and if the server allows the client to be a proxy for the LPD user. 192 NOTE: This specification does not define how the mapper maps the LPD 193 Printer-name operand to the IPP "printer-uri" parameter. 194 3.4 Send queue state (long) 195 Command syntax: 196 send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF 197 The mapper.s response to this command includes information about the 198 printer and its jobs. RFC 1179 specifies neither the information nor the 199 format of its response. This document requires the mapper to follow 200 existing practice as specified in this document. 201 The mapper SHALL produce a response in the following format which 202 consists of a printer-status line optionally followed a list of jobs, 203 where each job consists of a blank line, a description line, and one 204 line for each file. The description line contains the user-name, rank, 205 job-number and host. This format is defined by examples below. Appendix 206 B contain the ABNF syntax. 207 For an printer with no jobs the response is: 208 no entries Herriot, Hastings, June 23, 1998, [Page 9] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 209 For a printer with jobs, an example of the response is: 210 killtree is ready and printing 211 212 fred: active [job 123 tiger] 213 2 copies of stuff 602 bytes 214 215 smith: 1st [job 124 snail] 216 2 copies of resume 7088 bytes 217 2 copies of foo 10200 bytes 218 219 fred: 2nd [job 125 tiger] 220 more 99 bytes 221 222 The column numbers of above headings and job entries are: 223 224 | | | 225 01 09 41 226 227 Although the format of the long form is different from the format of the 228 short form, their fields are identical except for a) the copies and host 229 fields which are only in the long form, and b) the .size. field 230 contains the single copy size of each file. Thus the sum of the file 231 sizes in the .size. field times the value of the .copies. field 232 produces the value for the .Total Size. field in the short form. For 233 fields other than the host and copies fields, see the preceding section. 234 For the host field see the table below. LPD field IPP attribute special conversion details host unspecified conversion; job- originating-host may be the mapper.s host copies copies the mapper shall assume the value of copies precedes the string .copies of .; otherwise, the value of copies is 1. 235 236 NOTE: This specification does not define how the mapper maps the LPD 237 Printer-name operand to the IPP printer-uri parameter. 238 3.5 Remove jobs 239 Command syntax: 240 remove-jobs = %x05 printer-name SP agent 241 *(SP(user-name / job-number)) LF 242 The agent operand is the user-name of the user initiating the remove- 243 jobs command. The special user-name 'root' indicates a privileged user 244 who can remove jobs whose user-name differs from the agent.. Herriot, Hastings, June 23, 1998, [Page 10] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 245 The mapper SHALL issue one Cancel-Job operation for each job referenced 246 by the remove-jobs command. Each job-number in the remove-jobs command 247 references a single job. Each user-name in the remove-jobs command 248 implicitly references all jobs owned by the specified user. The active 249 job is implicitly referenced when the remove-jobs command contains 250 neither job-numbers nor user-names. The mapper MAY use Get-Jobs to 251 determine the job-uri of implicitly referenced jobs. 252 The mapper SHALL not use the agent name of .root. when end-users cancel 253 their own jobs. Violation of this rule creates a potential security 254 violation, and it may cause the printer to issue a notification that 255 misleads a user into thinking that some other person canceled the job. 256 If the agent of a remove-jobs command for a job J is the same as the 257 user name specified with the .P. function in the control file for job J, 258 then the mapper SHALL ensure that the caller of the Cancel-Job command 259 for job J is the same as job-originating-user for job J. 260 Note: This requirement means that a mapper must be consistent in who the 261 receiver perceives as the caller of IPP operations. The mapper either 262 acts as itself or acts on behalf of another user. The latter is 263 preferable if it is possible. This consistency is necessary between 264 Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but 265 it is also desirable for other operations. For example, Get-Jobs may 266 give more information about job submitted by the caller of this 267 operation. 268 NOTE: This specification does not define how the mapper maps: (1) the 269 LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to 270 the IPP "job-uri". 271 NOTE: This specification does not specify how the mapper maps the LPD 272 user-name to the IPP job-originating-user because the mapper may use its 273 own user-name with jobs. 274 4. Mapping of LPD Control File Lines to IPP Parameters 275 This section describes the mapping from LPD control file lines (called 276 .functions.) to IPP operation input parameters. The mapper receives the 277 control file lines via the LPD receive-control-file sub-command.. Each 278 of the LPD functions appear as sub-sections of section 7 of RFC 1179. 279 In LPD control file lines, the text operands have a maximum length of 31 280 or 99 while IPP input parameters have a maximum of 255 characters. 281 Therefore, no data is lost. 282 The mapper converts each supported LPD function to its corresponding IPP 283 parameter as defined by tables in the subsections that follow. These 284 subsections group functions according to whether they are: 285 @ required with a job, 286 @ optional with a job Herriot, Hastings, June 23, 1998, [Page 11] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 287 @ required with each document. 288 In the tables below, each LPD value is given a name, such as .h.. If an 289 IPP value uses the LPD value, then the IPP value column contains the LPD 290 name, such as .h. to denote this. Otherwise, the IPP value column 291 specifies the literal value. 292 4.1 Required Job Functions 293 The following LPD functions MUST be in a received LPD job. The mapper 294 SHALL receive each of the following LPD functions and SHALL include the 295 information as a parameter with each IPP job. The functions SHOULD be in 296 the order .H., .P. and they SHOULD be the first two functions in the 297 control file, but they MAY be anywhere in the control file and in any 298 order. LPD function IPP name value description name value H h Originating Host h (in security layer) P u User identification requesting- u (and in security user-name layer) none ipp- .true. attribute- fidelity 299 A mapper MAY sends its own host rather than the client.s host, and a 300 mapper MAY send its own user-name as user identification rather than the 301 client user. But in any case, the values sent SHALL be compatible with 302 the Cancel-Job operation. The IPP operation MAY have no way to specify 303 an originating host-name. 304 The mapper SHALL include ipp-attribute-fidelity =true so that it doesn.t 305 have to determine which attributes a printer supports. 306 4.2 Optional Job Functions 307 The following LPD functions MAY be in a received job. These function 308 SHOULD follow the required job functions and precede the document 309 functions, but they MAY be anywhere in the control file. 310 If the mapper receives such an LPD function, the mapper SHALL include 311 the corresponding IPP attribute with the value converted as specified in 312 the table below. If the mapper does not receive such an LPD attribute, 313 the mapper SHALL NOT include the corresponding IPP attribute, except the 314 .L. LPD function whose absence has a special meaning as noted in the 315 table. LPD function IPP Herriot, Hastings, June 23, 1998, [Page 12] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 name value description name value J j Job name for job-name j banner page L l Print banner page job-sheets .standard. if .L. is present .none. if .L. is present M m Mail When Printed IPP has no notification mechanism. To support this LPD feature, the gateway must poll 316 . 317 4.3 Required Document Functions 318 The mapper SHALL receive one set of the required document functions with 319 each copy of a document, and SHALL include the converted information as 320 parameters with each IPP document 321 If the control file contains required and recommended document 322 functions, the required functions SHOULD precede the recommended ones 323 and if the job contains multiple documents, all the functions for each 324 document are grouped together as shown in the example of section 6.3 325 .Required Document Functions.. However, the document functions MAY be in 326 any order. 327 LPD function IPP name valu description name value e f fff Print formatted document-format 'application/octet- file stream' l fff Print file leaving document-format 'application/octet- control characters stream' o fff Print Postscript document-format 'application/PostScri output file pt' copies see note 328 Note: In practice, the .f. LPD function is often overloaded. It is often 329 used with any format of document data including PostScript and PCL data. 330 Note: In practice, the .l. LPD function is often used as a rough 331 equivalent to the .f. function. 332 Note: When RFC 1179 was written, no implementation supported the .o. 333 function; instead .f. was used for PostScript. Windows NT now sends .o. 334 function for a PostScript file. 335 Note: the value .fff. of the .f., .l. and .o. functions is the name of 336 the data file as transferred, e.g. .dfA123woden.. Herriot, Hastings, June 23, 1998, [Page 13] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 337 If the mapper receives any other lower case letter, the mapper SHALL 338 reject the job because the document contains a format that the mapper 339 does not support. 340 The mapper determines the number of copies by counting the number of 341 occurrences of each .fff. file with one of the lower-case functions 342 above. For example, if .f dfA123woden. occurs 4 times, then copies has a 343 value of 4. Although the LPD protocol allows the value of copies to be 344 different for each document, the commands and the receiving print 345 systems don.t support this. 346 4.4 Recommended Document Functions 347 The mapper SHOULD receive one set of the recommended document functions 348 with each document, and SHOULD include the converted information as 349 parameters with each IPP document. The functions SHOULD be received in 350 the order .U. and .N., but they MAY arrive in any order. LPD function IPP name value description name value U fff ignored N n Name of source file document-name n 351 Note: the value .fff. of the .U. function is the name of the data file 352 as transferred, e.g. .dfA123woden.. 353 5. Mapping from IPP operations to LPD commands 354 If the IPP-to-LPD mapper receives an IPP operation, the following table 355 summarizes the LPD command that it uses. Each section below gives the 356 detail. Each of the following sub-sections appear as sub-sections of 357 section 3 in the document "Internet Printing Protocol/1.0: Model and 358 Semantics" [ipp-mod]. IPP operation LPD command Print-Job or Print-URI or receive-a-printer-job Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs Validate-Job implemented by the mapper Cancel-Job remove-jobs Get-Printer-Attributes, Get-Job- send queue state (short or long) Attributes or Get-Jobs 359 5.1 Print-Job 360 The mapper SHALL send the following commands in the order listed below: 361 @ receive-a-printer-job command Herriot, Hastings, June 23, 1998, [Page 14] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 362 @ both receive-control-file sub-command and receive-data-file 363 sub-command 364 (unspecified order, see Note below) 365 @ print-any-waiting-jobs command, 366 except that if the mapper is sending a sequence of receive-a- 367 printer-job commands, it MAY omit sending print-any-waiting- 368 jobs after any receive-a printer-job command that is neither 369 the first nor last command in this sequence 370 Note: it is recommended that the order of the receive-control-file sub- 371 command and the receive-data-file sub-command be configurable because 372 either order fails for some print systems. Some print systems assume 373 that the control file follows all data files and start printing 374 immediately on receipt of the control file. When such a print system 375 tries to print a data file that has not arrived, it produces an error. 376 Other print systems assume that the control file arrives before the data 377 files and start printing when the first data file arrives. Such a system 378 ignores the control information, such as banner page or copies. 379 NOTE: This specification does not define the mapping between the IPP 380 printer-uri and the LPD printer-name. 381 The mapper SHALL send the IPP parameters and attributes received from 382 the operation to the LPD printer by using the LPD receive-control-file 383 sub-command. The mapper SHALL create the LPD job-number for use in the 384 control file name, but the receiving printer MAY, in some circumstances, 385 assign a different job-number to the job. The mapper SHALL create the 386 IPP job-id and IPP job-uri returned in the Print-Job response. 387 NOTE: This specification does not specify how the mapper determines the 388 LPD job-number, the IPP job-id or the IPP job-uri of a job that it 389 creates nor does it specify the relation ship between the IPP job-uri, 390 IPP the job-id and the LPD job-number, both of which the mapper creates. 391 However, it is likely that the mapper will use the same integer value 392 for both theLPD job-number and the IPP job-id, and that the IPP Job-uri 393 is the printer.s URI with the job-id concatenated on the end. 394 The mapper SHALL send data received in the IPP operation to the LPD 395 printer by using the LPD receive-data-file sub-command. The mapper SHALL 396 specify the exact number of bytes being transmitted in the number-of- 397 bytes field of the receive-data-file sub-command. It SHALL NOT use a 398 value of 0 in this field. 399 If the mapper, while it is transmitting a receive-a-printer-job command 400 or sub-command, either detects that its IPP connection has closed or 401 receives a Cancel-Job operation, the mapper SHALL terminate the LPD job 402 either with the abort sub-command or the remove-jobs command. 403 ISSUE: error code conversion. Herriot, Hastings, June 23, 1998, [Page 15] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 404 5.2 Print-URI 405 The mapper SHALL handle this operation in the same way as a Print-Job 406 operation except that it SHALL obtain data referenced by the .document- 407 uri. parameter and SHALL then treat that data as if it had been received 408 via a Print-Job operation. 409 5.3 Validate-Job 410 The mapper SHALL perform this operation directly. Because LPD supports 411 very few attributes, this operation doesn.t have much to check. 412 5.4 Create-Job 413 The mapper SHALL handle this operation like Print-Job, except 414 @ the mapper SHALL send the control file after it has received 415 the last Send-Document or Send-URI operation because the 416 control file contains all the document-name and document- 417 format values specified in the Send-Document and Send-URI 418 operations. 419 @ the mapper SHALL perform one receive-data-file sub-command for 420 each Send-Document or Send-URI operation received and in the 421 same order received. 422 @ the mapper SHALL send the control file either before all data 423 files or after all data files. 424 (See the note in the section on Print-Job about the dilemma of 425 sending the control file either before or after the data 426 files. 427 5.5 Send-Document 428 The mapper performs a receive-data-file sub-command on the received 429 data. See the preceding section 5.4 .Create-Job. for the details. 430 5.6 Send-URI 431 The mapper SHALL obtain the data referenced by the .document-uri. 432 parameter, and SHALL then treat that data as if it had been received via 433 a Send-Document operation. See the preceding section 5.5 .Send-Document. 434 for the details. 435 5.7 Cancel-Job 436 The mapper SHALL perform a remove-jobs command with the following 437 parameters: Herriot, Hastings, June 23, 1998, [Page 16] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 438 @ the printer is the one to which the job was submitted, that is 439 the IPP printer-uri is mapped to an LPD printer-name by the 440 same mechanism as for all commands. , 441 @ the agent is the authenticated user-name of the IPP client, 442 @ the job-number is the job-id returned by the Print-Job 443 command, that is, the LPD job-number has the same value as the 444 IPP job-id for likely implementations. . 445 5.8 Get-Printer-Attributes 446 LPD severely limits the set of attributes that the mapper is able to 447 return in its response for this operation. The mapper SHALL support, at 448 most, the following printer attributes: 449 @ printer-state 450 @ printer-state-reasons 451 The mapper uses either the long or short form of the .send queue state. 452 command. 453 The mapper SHALL assume that the LPD response that it receives has the 454 format and information specified in section 3.3 .Send queue state 455 (short). and section 3.4 .Send queue state (long).. The mapper SHALL 456 determine the value of each requested attribute by using the inverse of 457 the mapping specified in the two aforementioned sections. 458 Note: the mapper can determine the response from the printer-status line 459 without examining the rest of the LPD response. 460 5.9 Get-Job-Attributes 461 LPD severely limits the set of attributes that the mapper is able to 462 return in its response for this operation. The mapper SHALL support, at 463 most, the following job attributes: 464 @ number-of-intervening-jobs 465 @ job-originating-user-name 466 @ job-id 467 @ document-name 468 @ job-k-octets 469 @ copies 470 The mapper uses either the long or short form of the .send queue state. 471 command. If it receives a request for the .job-k-octets. or .copies. 472 and supports the attribute it SHALL use the long form; otherwise, it 473 SHALL use the short form. 474 Note: the value of job-k-octets is the value in the short form divided 475 by the number of .copies. which is on the long form only. Its value can 476 also be determined by adding the .size. field values for each document 477 in the job in the long form. Herriot, Hastings, June 23, 1998, [Page 17] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 478 The mapper SHALL assume that the LPD response that it receives has the 479 format and information specified in section 3.3 .Send queue state 480 (short). and section 3.4 .Send queue state (long).. The mapper SHALL 481 determine the value of each requested attribute by using the inverse of 482 the mapping specified in the two aforementioned sections. 483 Note: when the mapper uses the LPD short form, it can determine the 484 response from the single LPD line that pertains to the job specified by 485 the Get-Job-Attributes operation. 486 NOTE: the mapper can use its correspondence between the IPP job-id, job- 487 uri and the LPD job-number. 488 5.10 Get-Jobs 489 The mapper SHALL perform this operation in the same way as Get-Job- 490 Attributes except that the mapper converts all the LPD job-lines, and 491 the IPP response contains one job object for each job-line in the LPD 492 response.. 493 6. Mapping of IPP Parameters to LPD Control File Lines 494 This section describes the mapping from IPP operation input parameters 495 to LPD control file lines (called .functions.). The mapper receives the 496 IPP operation input parameters via the IPP operation. Each of the IPP 497 operation input parameters appear as sub-sections of section 3 and 4.2 498 in the IPP model document [ipp-mod]. 499 In the context of LPD control file lines, the text operands have a 500 maximum length of 31 or 99 while IPP input parameters have a maximum of 501 255 characters. Therefore, there may be some data loss if the IPP 502 parameters exceed the maximum length of the LPD equivalent operands. 503 The mapper converts each supported IPP parameter to its corresponding 504 LPD function as defined by tables in the subsections that follow. These 505 subsections group functions according to whether they are: 506 @ required with a job, 507 @ optional with a job 508 @ required with each document. 509 In the tables below, each IPP value is given a name, such as .h.. If an 510 LPD value uses the IPP value, then the LPD value column contains the IPP 511 name, such as .h. to denote this. Otherwise, the LPD value column 512 specifies the literal value. Herriot, Hastings, June 23, 1998, [Page 18] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 513 6.1 Required Job Functions 514 The mapper SHALL include the following LPD functions with each job, and 515 they SHALL have the specified value. They SHALL be the first functions 516 in the control file and they SHALL be in the order .H. and then .P.. IPP LPD function name value name value description (perhaps in security h H gateway host Originating Host layer) requesting-user-name u P u User identification and in the security layer 517 A mapper SHALL sends its own host rather than the client.s host, because 518 some LPD systems require that it be the same as the host from which the 519 remove-jobs command comes. A mapper MAY send its own user name as user 520 identification rather than the client user. But in any case, the values 521 sent SHALL be compatible with the LPD remove-jobs operation. 522 6.2 Optional Job Functions 523 The mapper MAY include the following LPD functions with each job. They 524 SHALL have the specified value if they are sent. These functions, if 525 present, SHALL follow the require job functions, and they SHALL precede 526 the required document functions. 527 IPP attribute LPD function name value nam value description e job-name j J j Job name for banner page job-sheets .standard. L u Print banner page job-sheets .none. omit .L. function 528 Note: .L. has special meaning when it is omitted. If .J. is omitted, 529 some undefined behavior occurs with respect to the banner page. 530 6.3 Required Document Functions 531 The mapper SHALL include one set of the following LPD functions with 532 each document, and they SHALL have the specified values. For each 533 document, the order of the functions SHALL be .f., .U. and then .N., 534 where .f. is replicated once for each copy. IPP attribute LPD function Herriot, Hastings, June 23, 1998, [Page 19] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 name value name value description document- 'application/octet- f fff Print formatted file format stream' or 'application/PostScrip t. copies c replicate .f. .c. times none U fff Unlink data file document- n N n Name of source file name 535 Note: the value .fff. of the .f. and .U. functions is the name of the 536 data file as transferred, e.g. .dfA123woden.. 537 Note: the mapper SHALL not send the .o. function 538 ISSUE: should we register DVI, troff or ditroff? 539 If the mapper receives no .ipp-attribute-fidelitybest-effort. or it has 540 a value of false, then the mapper SHALL reject the job if it specifies 541 attributes or attribute values that are not among those supported in the 542 above tables. 543 Below is an example of the minimal control file for a job with three 544 copies of two files .foo. and .bar.: 545 H tiger 546 P jones 547 f dfA123woden 548 f dfA123woden 549 f dfA123woden 550 U dfA123woden 551 N foo 552 f dfB123woden 553 f dfB123woden 554 f dfB123woden 555 U dfB123woden 556 N bar 557 7. Security Considerations 558 There are no security issues beyond those covered in the IPP protocol 559 document [ipp-enc], the IPP model document [ipp-mod] and the LPD 560 document [rfc1179]. 561 8. References 562 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 563 "Internet Printing Protocol/1.0: Model and Semantics", , June, 1998. Herriot, Hastings, June 23, 1998, [Page 20] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 565 [ipp-enc] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet 566 Printing Protocol/1.0: Encoding and transport", , June 1998. 568 [rfc1179] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, 569 August 1990. 570 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 571 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 572 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate 573 Requirement Levels", RFC 2119 , March 1997 574 [abnf] D. Crocker et al., .Augmented BNF for Syntax Specifications: 575 ABNF., draft-ietf-drums-abnf-05.txt. 576 9. Author's Addresses Robert Herriot (editor) Norm Jacobs Sun Microsystems Inc. Sun Microsystems Inc. 901 San Antonio.Road., MPK-17 1430 Owl Ridge Rd. Mountain View, CA 94043 Colorado Springs, CO 80919 Phone: 650-786-8995 Phone: 719-532-9927 Fax: 650-786-7077 Fax: 719-535-0956 Email: robert.herriot@eng.sun.com Email: Norm.Jacobs@Central.sun.com Thomas N. Hastings Jay Martin Xerox Corporation Underscore, Inc. 701 S. Aviation Blvd., ESAE-231 41-C Sagamore Park Road El Segundo, CA 90245 Hudson, NH 03051-4915 Phone: 310-333-6413 Phone: 603-889-7000 Fax: 310-333-5514 Fax: 603-889-2699 EMail: hastings@cp10.es.xerox.com Email: jkm@underscore.com 577 578 10. Appendix A: ABNF Syntax for response of Send-queue-state (short) 579 The syntax in ABNF for the response to the LPD command .send-queue-state 580 (long). is: 581 status-response = empty-queue / nonempty-queue 582 empty-queue = .no-entries. LF 583 nonempty-queue = printer-status LF heading LF *(job LF) 584 printer-status = OK-status / error-status 585 OK-status = printer-name SP .ready and printing. LF 586 error-status = < implementation dependent status information > 587 heading = .Rank. 3SP .Owner. 6SP .Job. 13SP .Files. 588 23SP .Total Size. LF Herriot, Hastings, June 23, 1998, [Page 21] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 589 ; the column headings and their values below begin 590 at the columns 591 ; 1, 8, 19, 35 and 63 592 job = rank *SP owner *SP job *SP files *SP total-size .bytes. 593 ; jobs are in order of oldest to newest 594 rank = .active. / .1st. / .2nd. / .3rd. / integer .th. 595 ; job that is printing is .active. 596 ; other values show position in the queue 597 owner = 598 job = 1*3DIGIT ; job-number 599 files = *( .,. ) ; truncated to 24 characters 600 total-size = 1*DIGIT ; combined size in bytes of all documents 601 11. Appendix B: ABNF Syntax for response of Send-queue-state (long) 602 The syntax in ABNF for the response to the LPD command .send-queue-state 603 (long). is: 604 status-response = empty-queue / nonempty-queue 605 empty-queue = .no-entries. LF 606 nonempty-queue = printer-status LF *job 607 printer-status = OK-status / error-status 608 OK-status = printer-name SP .ready and printing. LF 609 error-status = < implementation dependent status information > 610 job = LF line-1 LF line-2 LF 611 line-1 = owner .:. SP rank 1*SP .[job. job SP host .]. 612 line-2 = file-name 1*SP document-size .bytes. 613 ; jobs are in order of oldest to newest 614 rank = .active. / .1st. / .2nd. / .3rd. / integer .th. 615 ; job that is printing is .active. 616 ; other values show position in the queue 617 owner = 618 job = 1*3DIGIT 619 file-name = [ 1*DIGIT .copies of. SP ] 620 ; truncated to 24 characters 621 document-size = 1*DIGIT ;size of single copy of the document. 622 12. Appendix C: Unsupported LPD functions 623 The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper 624 ignores them and the IPP-to-LPD mapper does not send them. LPD command name description C Class for banner page I Indent Printing H Host of client M Mail when printed S Symbolic link data T Title for pr W Width of output 1 troff R font Herriot, Hastings, June 23, 1998, [Page 22] Jacobs, Martin Expires December 23, 1998 INTERNET DRAFT Mapping between LPD and IPP Protocols June 23, 1998 2 troff I font 3 troff B font 4 troff S font 625 626 The follow LPD functions specify document-formats which have no IPP 627 equivalent, unless someone registers them. The LPD-to-IPP mapper rejects 628 jobs that request such a document format, and the IPP-to-LPD mapper does 629 not send them. LPD command name description c Plot CIF file d Print DVI file g Plot file k reserved for Kerberized clients and servers n Print ditroff output file p Print file with 'pr' format r File to print with FORTRAN carriage control t Print troff output file v Print raster file z reserved for future use with the Palladium print system 630 631 13. Appendix D: Full Copyright Statement 632 Copyright (C)The Internet Society (1997). All Rights Reserved 633 This document and translations of it may be copied and furnished to 634 others, and derivative works that comment on or otherwise explain it or 635 assist in its implementation may be prepared, copied, published and 636 distributed, in whole or in part, without restriction of any kind, 637 provided that the above copyright notice and this paragraph are included 638 on all such copies and derivative works. However, this document itself 639 may not be modified in any way, such as by removing the copyright notice 640 or references to the Internet Society or other Internet organizations, 641 except as needed for the purpose of developing Internet standards in 642 which case the procedures for copyrights defined in the Internet 643 Standards process must be followed, or as required to translate it into 644 languages other than English. 645 The limited permissions granted above are perpetual and will not be 646 revoked by the Internet Society or its successors or assigns. 647 This document and the information contained herein is provided on an .AS 648 IS. basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 649 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 650 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 651 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 652 FITNESS FOR A PARTICULAR PURPOSE. 653 Herriot, Hastings, June 23, 1998, [Page 23] Jacobs, Martin Expires December 23, 1998