idnits 2.17.1 draft-ietf-ipp-lpd-ipp-map-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 37 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 148 has weird spacing: '...ommands to IP...' == Line 172 has weird spacing: '...If the mapper...' == Line 189 has weird spacing: '...ate-Job opera...' == Line 195 has weird spacing: '... single data ...' == Line 196 has weird spacing: '...AY use the ...' == (39 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The mapper SHALL not use the agent name of `root' when end-users cancel their own jobs. Violation of this rule creates a potential security violation, and it may cause the printer to issue a notification that misleads a user into thinking that some other person canceled the job. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Note: the mapper SHALL not send the `o' function -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 30, 1998) is 9581 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) == Unused Reference: '5' is defined on line 946, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1179 (ref. '3') ** Obsolete normative reference: RFC 1759 (ref. '4') (Obsoleted by RFC 3805) == Outdated reference: A later version (-04) exists of draft-ietf-drums-abnf-03 Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 4 Robert Herriot (editor) 5 Sun Microsystems, Inc. 6 Tom Hastings 7 Xerox Corporation 8 Norm Jacobs 9 Sun Microsystems, Inc. 10 Jay Martin 11 Underscore, Inc. 12 July 30, 1997 14 Mapping between LPD and IPP Protocols 15 16 Expires Jan 30, 1998 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, and 22 its working groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Abstract 39 This Internet-Draft specifies the mapping between (1) the commands 40 and operands of the "Line Printer Daemon (LPD) Protocol" specified 41 in RFC 1179 and (2) the operations and parameters of the Internet 42 Printing Protocol (IPP). One of the purposes of this document is 43 to compare the functionality of the two protocols. Another purpose 44 is to facilitate implementation of gateways between LPD and IPP. 46 WARNING: RFC 1179 was not on standards track. While RFC 1179 was 47 intended to record existing practice, it fell short in some areas. 48 However, this specification maps between (1) the actual current 49 practice of RFC 1179 and (2) IPP. This document does not attempt 50 to map the numerous divergent extensions to the LPD protocol that 51 have been made by many implementers. 53 TABLE OF CONTENTS 55 1. Introduction........................................................3 56 2. Terminology.........................................................3 57 3. Mapping from LPD Commands to IPP Operations.........................4 58 3.1 Print any waiting jobs ...........................................4 59 3.2 Receive a printer job ............................................4 60 3.2.1 Abort job ....................................................5 61 3.2.2 Receive control file .........................................6 62 3.2.3 Receive data file ............................................6 63 3.3 Send queue state (short) .........................................6 64 3.4 Send queue state (long) ..........................................8 65 3.5 Remove jobs ......................................................9 66 4. Mapping of LPD Control File Lines to IPP Parameters................10 67 4.1 Required Job Functions ..........................................10 68 4.2 Optional Job Functions ..........................................11 69 4.3 Required Document Functions .....................................12 70 4.4 Recommended Document Functions ..................................13 71 5. Mapping from IPP operations to LPD commands........................13 72 5.1 Get-Operations ..................................................13 73 5.2 Print-Job .......................................................13 74 5.3 Print-URI .......................................................14 75 5.4 Validate-Job ....................................................15 76 5.5 Create-Job ......................................................15 77 5.6 Send-Document ...................................................15 78 5.7 Send-URI ........................................................15 79 5.8 Cancel-Job ......................................................15 80 5.9 Get-Attributes ..................................................16 81 5.10 Get-Jobs .......................................................17 82 6. Mapping of IPP Parameters to LPD Control File Lines................17 83 6.1 Required Job Functions ..........................................17 84 6.2 Optional Job Functions ..........................................18 85 6.3 Required Document Functions .....................................18 86 7. References.........................................................19 87 8. Author's Addresses.................................................19 88 9. Appendix A: ABNF Syntax for response of Send-queue-state (short)...20 89 10. Appendix B: ABNF Syntax for response of Send-queue-state (long)...20 90 11. Appendix C: Unsupported LPD functions.............................21 91 Mapping between the LPD and IPP Protocols 93 1. Introduction 95 The reader of this specification is expected to be familiar with the IPP 96 Model and Semantics specification [1], the IPP Protocol specification 97 [2], and the Line Printer Daemon (LPD) protocol specification [3] as 98 described in RFC 1179. 100 RFC 1179 was written in 1990 in an attempt to document existing LPD 101 protocol implementations. Since then, a number of undocumented 102 extensions have been made by vendors to support functionality specific 103 to their printing solutions. All of these extensions consist of 104 additional control file commands. This document does not address any of 105 these vendor extensions. Rather it addresses existing practice within 106 the context of the features described by RFC 1179. Deviations of 107 existing practice from RFC 1179 are so indicated. 109 Other LPD control file commands in RFC 1179 are obsolete. They are 110 intended to work on "text" only formats and are inappropriate for many 111 contemporary document formats that completely specify each page. This 112 document does not address the support of these obsolete features. 114 In the area of document formats, also known as page description 115 languages (PDL), RFC 1179 defines a fixed set with no capability for 116 extension. Consequently, some new PDL's are not supported, and some of 117 those that are supported are sufficiently unimportant now that they have 118 not been registered for use with the Printer MIB[4] and IPP[1] [2], 119 though they could be registered if desired. See the Printer MIB 120 specification [4] and/or the IPP Model specification [1] for 121 instructions for registration of document-formats with IANA. IANA lists 122 the registered document-formats as "printer languages". 124 This document addresses the protocol mapping for both directions: 125 mapping of the LPD protocol to the IPP protocol and mapping of the IPP 126 protocol to the LPD protocol. The former is called the "LPD-to-IPP 127 mapper" and the latter is called the "IPP-to-LPD mapper". 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [6]. 135 RFC 1179 uses the word "command" in two contexts: for over-the-wire 136 operations and for command file functions. This document SHALL use the 137 word "command" for the former and the phrase "functions" for the latter. 138 The syntax of the LPD commands is given using ABNF [6]. 140 The following tokens are used in order to make the syntax more readable: 142 LF stands for %x0A (linefeed) 143 SP stands for %x20. (space) 144 DIGIT stands for %x30-39 ("0" to "9") 146 3. Mapping from LPD Commands to IPP Operations 148 This section describes the mapping from LPD commands to IPP operations. 149 Each of the following sub-sections appear as sub-sections of section 5 150 of RFC 1179. 152 The following table summarizes the IPP operation that the mapper uses 153 when it receives an LPD command. Each section below gives more detail. 155 LPD command IPP operation 157 print-any-waiting-jobs ignore 158 receive-a-printer-job Print-Job or Create-Job/Send-Document 159 send queue state Get-Attributes (printer) and Get-Jobs 160 (short or long) 161 remove-jobs Cancel-Job 163 3.1 Print any waiting jobs 165 Command syntax: 167 print-waiting-jobs = %x01 printer-name LF 169 This command causes the LPD daemon check its queue and print any waiting 170 jobs. An IPP printer handles waiting jobs without such a nudge. 172 If the mapper receives this LPD command, it SHALL ignore it and send no 173 IPP operation. 175 3.2 Receive a printer job 177 Command syntax: 179 receive-job = %x02 printer-name LF 181 The control file and data files mentioned in the following paragraphs 182 are received via LPD sub-commands that follow this command. Their 183 mapping to IPP commands and attributes is described later in this 184 section. 186 The mapper maps the 'Receive a printer job' command to either: 188 . the Print-Job operation which includes a single data file or 189 . the Create-Job operation followed by one Send-Document 190 operation for each data file. 192 If the IPP printer supports both Create-Job and Send-Document, and if a 193 job consists of: 195 . a single data file, the mapper SHOULD use the PrintJob 196 operation, but MAY use the Create-Job and Send-Document 197 operations. 198 . more than one data file, the mapper SHALL use Create Job 199 followed by one Send-Document for each received LPD data file. 201 If the IPP printer does not support both Create-Job and Send-Document, 202 and if a job consists of: 204 . a single data file, the mapper SHALL use the PrintJob 205 operation. 206 . more than one data file, the mapper SHALL submit each received 207 LPD data file as a separate Print-Job operation (thereby 208 converting a single LPD job into multiple IPP jobs). 210 If the mapper uses Create-Job and Send-Document, it MUST send the 211 Create-Job operation before it sends any Send-Document operations 212 whether the LPD control file, which supplies attributes for Create-Job, 213 arrives before or after all LPD data files. 215 NOTE: This specification does not specify how the mapper maps: the LPD 216 Printer-name operand to the IPP "printer-uri" parameter. 218 The following 3 sub-sections gives further details about the mapping 219 from LPD receive-a-printer-job sub-commands. Each of the following 220 sub-sections appear as sub-sections of section 6 of RFC 1179. 222 ISSUE: the mapper needs to maintain information such as the mapping of 223 each job-number to its corresponding job-URI. It would be nice for IPP 224 to support an "scratch-pad" attribute for the mapper to encode such 225 information. Then it wouldn't have to maintain this information 226 separately. 228 3.2.1 Abort job 230 Sub-command syntax: 232 abort-job = %x1 LF 234 This sub-command of receive-a-printer-job is intended to abort any job 235 transfer in process. 237 If the mapper receives this sub-command, it SHALL cancel the job that it 238 is in the process of transmitting. 240 If the mapper is in the process of sending a Print-Job or Create-Job 241 operation, it terminates the job either by closing the connection, or 242 performing the Cancel-Job operation with the job-uri that it received 243 from the Print-Job or Create-Job operation. 245 NOTE: This sub-command is implied if at any time the connection between 246 the LPD client and server is terminated before an entire print job has 247 been transferred via an LPD Receive-a-printer-job request. 249 3.2.2 Receive control file 251 Sub-command syntax: 253 receive-control-file = %x2 number-of-bytes SP name-of-control-file LF 254 number-of-bytes = 1*DIGIT 255 name-of-control-file = "cfA" job-number client-host-name 256 ; e.g. "cfA123woden" 257 job-number = 3DIGIT 258 client-host-name = 260 This sub-command is roughly equivalent to the IPP Create-Job operation. 262 The mapper SHALL use the contents of the received LPD control file to 263 create IPP parameter and attribute values to transmit with the Print-Job 264 or Create-Job operation. 266 3.2.3 Receive data file 268 Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file 270 receive-data-file = %x03 number-of-bytes SP name-of-data-file LF 271 number-of-bytes = 1*DIGIT 272 name-of-data-file = "df" letter job-number client-host-name 273 ; e.g. "dfA123woden for the first file 274 letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z" 275 ; first file is "A", 276 ; second "B", and 52nd file is "z" 277 job-number = 3DIGIT 278 client-host-name = 280 This sub-command is roughly equivalent to the IPP Send-Document 281 operation. 283 The mapper SHALL use the contents of the received LPD data file as the 284 data to transmit with the IPP Print-Job or Send-Document operation. 286 Although RFC-1179 alludes to a method for passing an unspecified 287 length data file by using an octet-count of zero, no implementations 288 support this feature.. The mapper SHALL reject a job that has a value of 289 0 in the number-of-bytes field. 291 3.3 Send queue state (short) 293 Command syntax: 295 send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF 297 The mapper's response to this command includes information about the 298 printer and its jobs. RFC 1179 specifies neither the information nor the 299 format of its response. This document requires the mapper to follow 300 existing practice as specified in this document. 302 The mapper SHALL produce a response in the following format which 303 consists of a printer-status line optionally followed by a heading line, 304 and a list of jobs. This format is defined by examples below. Appendix A 305 contains the ABNF syntax. 307 For an printer with no jobs, the response starts in column 1 and is: 309 no entries 311 For a printer with jobs, an example of the response is: 313 killtree is ready and printing 314 Rank Owner Job Files Total Size 315 active fred 123 stuff 1204 bytes 316 1st smith 124 resume, foo 34576 bytes 317 2nd fred 125 more 99 bytes 318 3rd mary 126 mydoc 378 bytes 319 4th jones 127 statistics.ps 4567 bytes 320 5th fred 128 data.txt 9 bytes 322 The column numbers of above headings and job entries are: 324 | | | | | 325 01 08 19 35 63 327 The mapper SHALL produce each field above from the following IPP 328 attribute: 330 LPD field IPP attribute special conversion details 332 printer- printer-state and For a printer-state of idle or 333 status printer-state-reasons processing, the mapper SHALL use 334 the formats above. For stopped, 335 the mapper SHALL use printer- 336 state-reasons to produce an 337 unspecified format for the error. 338 rank number-of- the mapper SHALL the format above 339 intervening-jobs 340 owner job-originating-user unspecified conversion; job- 341 originating-user may be the 342 mapper's user-name 343 job job-uri unspecified conversion 344 files document-name the mapper shall create a comma 345 separated list of the document- 346 names and then truncate this list 347 to the first 24 characters 348 total- job-k-octets the mapper shall multiple the 349 size value of job-k-octets by 1024. 351 A mapper SHOULD use the job attribute number-of-intervening-jobs rather 352 than the job's position in a list of jobs to determine `rank' because a 353 Printer may omit jobs that it wants to keep secret. If a printer doesn't 354 support the job attribute number-of-intervening-jobs, a mapper MAY use 355 the job's position. 357 ISSUE: is job-k-octets the sum of the bytes of each document times the 358 number of copies? If so, "total-size" is 1024 times job-k-octets. The 359 model document needs clarification. 361 In order to obtain the information specified above, The LPD-to-IPP 362 mapper SHALL use the Get-Attributes operation of the printer to get 363 printer-status and SHOULD use the Get-Jobs operation to get information 364 about all of the jobs. If the LPD command contains job-numbers or user- 365 names, the mapper handles the filtering of the response because Get-Jobs 366 has no way to limit jobs to those of a particular user. If the LPD 367 command contains job-numbers but no user-names, the mapper MAY use Get- 368 Attributes on each converted job-number rather than Get-Jobs. 370 NOTE: This specification does not define how the mapper maps the LPD 371 Printer-name operand to the IPP "printer-uri" parameter. 373 3.4 Send queue state (long) 375 Command syntax: 377 send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF 379 The mapper's response to this command includes information about the 380 printer and its jobs. RFC 1179 specifies neither the information nor the 381 format of its response. This document requires the mapper to follow 382 existing practice as specified in this document. 384 The mapper SHALL produce a response in the following format which 385 consists of a printer-status line optionally followed a list of jobs, 386 where each job consists of a blank line, a description line, and one 387 line for each file. The description line contains the user-name, rank, 388 job-number and host. This format is defined by examples below. Appendix 389 B contain the ABNF syntax. 391 For an printer with no jobs the response is: 393 no entries 395 For a printer with jobs, an example of the response is: 397 killtree is ready and printing 399 fred: active [job 123 tiger] 400 2 copies of stuff 602 bytes 402 smith: 1st [job 124 snail] 403 2 copies of resume 7088 bytes 404 2 copies of foo 10200 bytes 406 fred: 2nd [job 125 tiger] 407 more 99 bytes 409 The column numbers of above headings and job entries are: 411 | | | 412 01 09 41 414 Although the format of the long form is different from the format of the 415 short form, their fields are identical except for the copies and host 416 fields which are only in the long form. For fields other than the host 417 and copies fields, see the preceding section. For the host field see the 418 table below. 420 LPD field IPP attribute special conversion details 422 host job-originating-host unspecified conversion; job- 423 originating-host may be the 424 mapper's host 425 copies copies the mapper shall assume the 426 value of copies precedes the 427 string "copies of "; otherwise, 428 the value of copies is 1. 430 NOTE: This specification does not define how the mapper maps the LPD 431 Printer-name operand to the IPP printer-uri parameter. 433 3.5 Remove jobs 435 Command syntax: 437 remove-jobs = %x05 printer-name SP agent 438 *(SP(user-name / job-number)) LF 440 The agent operand is the user-name of the user initiating the remove- 441 jobs command. The special user-name 'root' indicates a privileged user 442 who can remove jobs whose user-name differs from the agent.. 444 The mapper SHALL issue one Cancel-Job operation for each job referenced 445 by the remove-jobs command. Each job-number in the remove-jobs command 446 references a single job. Each user-name in the remove-jobs command 447 implicitly references all jobs owned by the specified user. The active 448 job is implicitly referenced when the remove-jobs command contains 449 neither job-numbers nor user-names. The mapper MAY use Get-Job to 450 determine the job-uri of implicitly referenced jobs. 452 The mapper SHALL not use the agent name of `root' when end-users cancel 453 their own jobs. Violation of this rule creates a potential security 454 violation, and it may cause the printer to issue a notification that 455 misleads a user into thinking that some other person canceled the job. 457 If the agent of a remove-jobs command for a job J is the same as the 458 user name specified with the `P' function in the control file for job J, 459 then the mapper SHALL ensure that the caller of the Cancel-Job command 460 for job J is the same as job-originating-user for job J. 462 Note: This requirement means that a mapper must be consistent in who the 463 receiver perceives as the caller of IPP operations. The mapper either 464 acts as itself or acts on behalf of another user. The latter is 465 preferable if it is possible. This consistency is necessary between 466 Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but 467 it is also desirable for other operations. For example, Get-Jobs may 468 give more information about job submitted by the caller of this 469 operation. 471 NOTE: This specification does not define how the mapper maps: (1) the 472 LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to 473 the IPP "job-uri". 475 NOTE: This specification does not specify how the mapper maps the LPD 476 user-name to the IPP job-originating-user because the mapper may use its 477 own user-name with jobs. 479 4. Mapping of LPD Control File Lines to IPP Parameters 481 This section describes the mapping from LPD control file lines (called 482 `functions') to IPP operation input parameters. The mapper receives the 483 control file lines via the LPD receive-control-file sub-command.. Each 484 of the LPD functions appear as sub-sections of section 7 of RFC 1179. 486 In LPD control file lines, the text operands have a maximum length of 31 487 or 99 while IPP input parameters have a maximum of 255 characters. 488 Therefore, no data is lost. 490 The mapper converts each supported LPD function to its corresponding IPP 491 parameter as defined by tables in the subsections that follow. These 492 subsections group functions according to whether they are: 494 . required with a job, 495 . optional with a job 496 . required with each document. 498 In the tables below, each LPD value is given a name, such as `h'. If an 499 IPP value uses the LPD value, then the IPP value column contains the LPD 500 name, such as `h' to denote this. Otherwise, the IPP value column 501 specifies the literal value. 503 4.1 Required Job Functions 505 The following LPD functions MUST be in a received LPD job. The mapper 506 SHALL receive each of the following LPD functions and SHALL include the 507 information as a parameter with each IPP job. The functions SHOULD be in 508 the order `H', `P' and they SHOULD be the first two functions in the 509 control file, but they MAY be anywhere in the control file and in any 510 order. 512 LPD function IPP 513 name value description name value 515 H h Originating Host h (in security layer) 516 P u User identification u (in security layer) 517 none best-effort `true' 519 A mapper MAY sends its own host rather than the client's host, and a 520 mapper MAY send its own user-name as user identification rather than the 521 client user. But in any case, the values sent SHALL be compatible with 522 the Cancel-Job operation. The IPP operation MAY have no way to specify 523 an originating host-name. 525 ISSUE: what do we do about job-orginating-host? 527 The mapper SHALL include best-effort=true so that it doesn't have to 528 determine which attributes a printer supports. 530 4.2 Optional Job Functions 532 The following LPD functions MAY be in a received job. These function 533 SHOULD follow the required job functions and precede the document 534 functions, but they MAY be anywhere in the control file. 536 If the mapper receives such an LPD function, the mapper SHALL include 537 the corresponding IPP attribute with the value converted as specified in 538 the table below. If the mapper does not receive such an LPD attribute, 539 the mapper SHALL NOT include the corresponding IPP attribute, except the 540 `L' LPD function whose absence has a special meaning as noted in the 541 table. 543 LPD function IPP 544 name value description name value 546 J j Job name for job-name j 547 banner page 548 L l Print banner page job-sheets `standard' if `L' is 549 present 550 `none' if `L' is present 551 M m Mail When Printed notification- `job-completion' 552 events 'mailto://'m`@'h 553 notification- 554 method 555 Note: `m' is the user name and not an email address. The mapper can 556 fabricate an email address with the source host. This email address 557 mail fail when the `h' is some intermediary host that doesn't know about 558 user `m'. But there is no better solution. 560 4.3 Required Document Functions 562 The mapper SHALL receive one set of the required document functions with 563 each copy of a document, and SHALL include the converted information as 564 parameters with each IPP document 566 If the control file contains required and recommended document 567 functions, the required functions SHOULD precede the recommended ones 568 and if the job contains multiple documents, all the functions for each 569 document are grouped together as shown in the example of section 6.3 570 "Required Document Functions". However, the document functions MAY be in 571 any order. 573 LPD function IPP 574 name valu description name value 575 e 577 f fff Print formatted document-format 37 (langAutomatic) 578 file 579 l fff Print file leaving document-format 37 (langAutomatic) 580 control characters 581 o fff Print Postscript document-format 6 (langPS). 582 output file 583 copies see note 584 Note: In practice, the `f' LPD function is often overloaded. It is often 585 used with any format of document data including PostScript and PCL data. 587 Note: In practice, the `l' LPD function is often used as a rough 588 equivalent to the `f' function. 590 Note: When RFC 1179 was written, no implementation supported the `o' 591 function; instead `f' was used for PostScript. Windows NT now sends `o' 592 function for a PostScript file. 594 Note: the value `fff' of the `f', `l' and `o' functions is the name of 595 the data file as transferred, e.g. "dfA123woden". 597 If the mapper receives any other lower case letter, the mapper SHALL 598 reject the job because the document contains a format that the mapper 599 does not support. 601 The mapper determines the number of copies by counting the number of 602 occurrences of each `fff' file with one of the lower-case functions 603 above. For example, if `f dfA123woden' occurs 4 times, then copies has a 604 value of 4. Although the LPD protocol allows the value of copies to be 605 different for each document, the commands and the receiving print 606 systems don't support this. 608 ISSUE: should we register DVI, ditroff and troff. At least DVI and one 609 of the troff is still in use. 611 4.4 Recommended Document Functions 613 The mapper SHOULD receive one set of the recommended document functions 614 with each document, and SHOULD include the converted information as 615 parameters with each IPP document. The functions SHOULD be received in 616 the order `U' and `N', but they MAY arrive in any order. 618 LPD function IPP 619 name value description name value 621 U fff ignored 622 N n Name of source file document-name n 624 Note: the value `fff' of the `U' function is the name of the data file 625 as transferred, e.g. "dfA123woden". 627 5. Mapping from IPP operations to LPD commands 629 If the IPP-to-LPD mapper receives an IPP operation, the following table 630 summarizes the LPD command that it uses. Each section below gives the 631 detail. Each of the following sub-sections appear as sub-sections of 632 section 3 in the document "Internet Printing Protocol/1.0: Model and 633 Semantics" [1]. 635 IPP operation LPD command 637 Get-Operations implemented by the mapper 638 Print-Job or Print-URI or receive-a-printer-job 639 Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs 640 Validate-Job implemented by the mapper 641 Cancel-Job remove-jobs 642 Get-Attributes (printer or job) send queue state (short or long) 643 or Get-Jobs 645 5.1 Get-Operations 647 The mapper SHALL return a list of the operations that it supports. It 648 SHALL support at least those operations that are mandatory according to 649 the IPP model document [1]. 651 5.2 Print-Job 653 The mapper SHALL send the following commands in the order listed below: 655 . receive-a-printer-job command 656 . both receive-control-file sub-command and receive-data-file 657 sub-command 658 (unspecified order, see Note below) 659 . print-any-waiting-jobs command, 660 except that if the mapper is sending a sequence of receive-a- 661 printer-job commands, it MAY omit sending print-any-waiting- 662 jobs after any receive-a printer-job command that is neither 663 the first nor last command in this sequence 665 Note: it is recommended that the order of the receive-control-file sub- 666 command and the receive-data-file sub-command be configurable because 667 either order fails for some print systems. Some print systems assume 668 that the control file follows all data files and start printing 669 immediately on receipt of the control file. When such a print system 670 tries to print a data file that has not arrived, it produces an error. 671 Other print systems assume that the control file arrives before the data 672 files and start printing when the first data file arrives. Such a system 673 ignores the control information, such as banner page or copies. 675 NOTE: This specification does not define the mapping between the IPP 676 printer-uri and the LPD printer-name. 678 The mapper SHALL send the IPP parameters and attributes received from 679 the operation to the LPD printer by using the LPD receive-control-file 680 sub-command. The mapper SHALL create the job-number for use in the 681 control file name, but the receiving printer MAY, in some circumstances, 682 assign a different job-number to the job. The mapper SHALL create the 683 job-uri returned in the Print-Job response. 685 NOTE: This specification does not specify how the mapper determines the 686 job-number or the job-uri of a job that it creates nor does it specify 687 the relation ship between the job-uri and the job-number, both of which 688 the mapper creates. 690 The mapper SHALL send data received in the IPP operation to the LPD 691 printer by using the LPD receive-data-file sub-command. The mapper SHALL 692 specify the exact number of bytes being transmitted in the number-of- 693 bytes field of the receive-data-file sub-command. It SHALL NOT use a 694 value of 0 in this field. 696 If the mapper, while it is transmitting a receive-a-printer-job command 697 or sub-command, either detects that its IPP connection has closed or 698 receives a Cancel-Job operation, the mapper SHALL terminate the LPD job 699 either with the abort sub-command or the remove-jobs command. 701 ISSUE: error code conversion. 703 5.3 Print-URI 705 The mapper SHALL handle this operation in the same way as a Print-Job 706 operation except that it SHALL obtain data referenced by the "document- 707 uri" parameter and SHALL then treat that data as if it had been received 708 via a Print-Job operation. 710 5.4 Validate-Job 712 The mapper SHALL perform this operation directly. Because LPD supports 713 very few attributes, this operation doesn't have much to check. 715 5.5 Create-Job 717 The mapper SHALL handle this operation like Print-Job, except 719 . the mapper SHALL send the control file after it has received 720 the last Send-Document or Send-URI operation because the 721 control file contains all the document-name and document- 722 format values specified in the Send-Document and Send-URI 723 operations. 724 . the mapper SHALL perform one receive-data-file sub-command for 725 each Send-Document or Send-URI operation received and in the 726 same order received. 727 . the mapper SHALL send the control file either before all data 728 files or after all data files. 729 (See the note in the section on Print-Job about the dilemma of 730 sending the control file either before or after the data 731 files. 733 5.6 Send-Document 735 The mapper performs a receive-data-file sub-command on the received 736 data. See the preceding section 5.5 "Create-Job" for the details. 738 5.7 Send-URI 740 The mapper SHALL obtain the data referenced by the "document-uri" 741 parameter, and SHALL then treat that data as if it had been received via 742 a Send-Document operation. See the preceding section 5.6 "Send-Document" 743 for the details. 745 5.8 Cancel-Job 747 The mapper SHALL perform a remove-jobs command with the following 748 parameters: 750 . the printer is the one containing the job specified by the IPP 751 job-uri, 752 . the agent is the authenticated user-name of the IPP client, 753 . the job-number is the one corresponding to the IPP job-uri 754 parameter. 756 NOTE: This specification does not specify how the mapper maps the IPP 757 "job-uri" to the LPD printer-name or LPD job-number. 759 ISSUE: the model needs to offer a solution for mapping jobs to printers 760 either with a new job attribute "printer-uri" or with all operation 761 targets being a printer-uri. 763 5.9 Get-Attributes 765 LPD severely limits the set of attributes that the mapper is able to 766 return in its response for this operation. 768 When the mapper receives a Get-Attributes operation for a printer 769 object, it SHALL support, at most, the following printer attributes: 771 . printer-state 772 . printer-state-reasons 774 When the mapper receives a Get-Attributes operation for a job object, it 775 SHALL support, at most, the following job attributes: 777 . number-of-intervening-jobs 778 . job-originating-user 779 . job-uri 780 . job-originating-host 781 . document-name 782 . job-k-octets 783 . copies 785 The mapper uses either the long or short form of the "send queue state" 786 command. If it receives a request for the "job-originating-host" or 787 "copies" and supports those attribute it SHALL use the long form; 788 otherwise, it SHALL use the short form. 790 Note: the value of job-k-octets is the value in the short form, but it 791 can be computed from the copies and file size fields in the long form. 793 The mapper SHALL assume that the LPD response that it receives has the 794 format and information specified in section 3.3 "Send queue state 795 (short)" and section 3.4 "Send queue state (long)". The mapper SHALL 796 determine the value of each requested attribute by using the inverse of 797 the mapping specified in the two aforementioned sections. 799 Note: when the mapper receives the Get-Attributes operation for a 800 printer, it can determine the response from the printer-status line 801 without examining the rest of the LPD response. When the mapper receives 802 the Get-Attributes operation for a job and uses the LPD short form, it 803 can determine the response from the single line that pertains to the job 804 specified by the Get-Attributes operation. 806 NOTE: For Get-Attributes of a job, this specification does not specify 807 how the mapper maps the IPP "job-uri" to the LPD printer-name or LPD 808 job-number. 810 5.10 Get-Jobs 812 The mapper SHALL perform this operation in the same way as Get- 813 Attributes of a printer except that the mapper converts the job-lines, 814 and the IPP response contains one job object for each job in the LPD 815 response.. 817 6. Mapping of IPP Parameters to LPD Control File Lines 819 This section describes the mapping from IPP operation input parameters 820 to LPD control file lines (called `functions'). The mapper receives the 821 IPP operation input parameters via the IPP operation. Each of the IPP 822 operation input parameters appear as sub-sections of section 3 and 4.2 823 in the IPP model document [1]. 825 In the context of LPD control file lines, the text operands have a 826 maximum length of 31 or 99 while IPP input parameters have a maximum of 827 255 characters. Therefore, there may be some data loss if the IPP 828 parameters exceed the maximum length of the LPD equivalent operands. 830 The mapper converts each supported IPP parameter to its corresponding 831 LPD function as defined by tables in the subsections that follow. These 832 subsections group functions according to whether they are: 834 . required with a job, 835 . optional with a job 836 . required with each document. 838 In the tables below, each IPP value is given a name, such as `h'. If an 839 LPD value uses the IPP value, then the LPD value column contains the IPP 840 name, such as `h' to denote this. Otherwise, the LPD value column 841 specifies the literal value. 843 6.1 Required Job Functions 845 The mapper SHALL include the following LPD functions with each job, and 846 they SHALL have the specified value. They SHALL be the first functions 847 in the control file and they SHALL be in the order "H" and then "P". 849 IPP LPD function 850 name value name value description 852 (in security layer) h H gateway host Originating Host 853 (in security layer) u P u User identification 855 A mapper SHALL sends its own host rather than the client's host, because 856 some LPD systems require that it be the same as the host from which the 857 remove-jobs command comes. A mapper MAY send its own user name as user 858 identification rather than the client user. But in any case, the values 859 sent SHALL be compatible with the LPD remove-jobs operation. 861 6.2 Optional Job Functions 863 The mapper MAY include the following LPD functions with each job. They 864 SHALL have the specified value if they are sent. These functions, if 865 present, SHALL follow the require job functions, and they SHALL precede 866 the required document functions. 868 IPP attribute LPD function 869 name value nam value description 870 e 872 job-name j J j Job name for banner 873 page 874 job-sheets `standard' L u Print banner page 875 job-sheets `none' omit `L' function 876 notification- `job-completion' user Mail When Printed 877 user`@' M events `mailto://' 878 notification- host 879 method 880 Note: `L' has special meaning when it is omitted. If `M' is omitted, 881 there is no notification. If `J' is omitted, some undefined behavior 882 occurs with respect to the banner page. 884 Note: the `user' for the `M' function comes from a substring of the 885 notification-method's value. 887 6.3 Required Document Functions 889 The mapper SHALL include one set of the following LPD functions with 890 each document, and they SHALL have the specified values. For each 891 document, the order of the functions SHALL be `f', `U' and then `N', 892 where `f' is replicated once for each copy. 894 IPP attribute LPD function 895 name value name value description 897 document- `37' (langAutomatic) f fff Print formatted file 898 format or `6' (langPS). 899 copies c replicate `f' `c' 900 times 901 none U fff Unlink data file 902 document- n N n Name of source file 903 name 904 Note: the value `fff' of the `f' and `U' functions is the name of the 905 data file as transferred, e.g. "dfA123woden". 907 Note: the mapper SHALL not send the `o' function 909 ISSUE: should we register DVI, troff or ditroff? 910 If the mapper receives no "best-effort" or it has a value of false, then 911 the mapper SHALL reject the job if it specifies attributes or attribute 912 values that are not among those supported in the above tables. 914 Below is an example of the minimal control file for a job with three 915 copies of two files `foo' and `bar': 917 H tiger 918 P jones 919 f dfA123woden 920 f dfA123woden 921 f dfA123woden 922 U dfA123woden 923 N foo 924 f dfB123woden 925 f dfB123woden 926 f dfB123woden 927 U dfB123woden 928 N bar 930 7. References 932 [1] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet 933 Printing Protocol/1.0: Model and Semantics", , July 1997. 936 [2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing 937 Protocol/1.0: Protocol specification", , 938 July 1997. 940 [3] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, August 941 1990. 943 [4] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., 944 "Printer MIB", RFC 1759, March 1995. 946 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 947 Levels", RFC 2119 , March 1997 949 [6] D. Crocker et al., "Augmented BNF for Syntax Specifications: ABNF", 950 draft-ietf-drums-abnf-03.txt. 952 8. Author's Addresses 954 Robert Herriot (editor) Norm Jacobs 955 Sun Microsystems Inc. Sun Microsystems Inc. 956 901 San Antonio.Road., MPK-17 1430 Owl Ridge Rd. 957 Mountain View, CA 94043 Colorado Springs, CO 80919 959 Phone: 650-786-8995 Phone: 719-532-9927 960 Fax: 650-786-7077 Fax: 719-535-0956 961 Email: robert.herriot@eng.sun.com Email: 962 Norm.Jacobs@Central.sun.com 964 Thomas N. Hastings Jay Martin 965 Xerox Corporation Underscore, Inc. 966 701 S. Aviation Blvd., ESAE-231 41-C Sagamore Park Road 967 El Segundo, CA 90245 Hudson, NH 03051-4915 969 Phone: 310-333-6413 Phone: 603-889-7000 970 Fax: 310-333-5514 Fax: 603-889-2699 971 EMail: hastings@cp10.es.xerox.com Email: jkm@underscore.com 973 9. Appendix A: ABNF Syntax for response of Send-queue-state (short) 975 The syntax in ABNF for the response to the LPD command `send-queue-state 976 (long)' is: 978 status-response = empty-queue / nonempty-queue 979 empty-queue = "no-entries" LF 980 nonempty-queue = printer-status LF heading LF *(job LF) 981 printer-status = OK-status / error-status 982 OK-status = printer-name SP "ready and printing" LF 983 error-status = < implementation dependent status information > 984 heading = "Rank" 3SP Owner 6SP "Job" 13SP "Files" 985 23SP "Total Size" LF 986 ; the column headings and their values below begin 987 at the columns 988 ; 1, 8, 19, 35 and 63 989 job = rank *SP owner *SP job *SP files *SP total-size "bytes" 990 ; jobs are in order of oldest to newest 991 rank = "active" / "1st" / "2nd" / "3rd" / integer "th" 992 ; job that is printing is "active" 993 ; other values show position in the queue 994 owner = 995 job = 1*3DIGIT ; job-number 996 files = *( "," ) ; truncated to 24 characters 997 total-size = 1*DIGIT ; combined size in bytes of all documents 999 10. Appendix B: ABNF Syntax for response of Send-queue-state (long) 1001 The syntax in ABNF for the response to the LPD command `send-queue-state 1002 (long)' is: 1004 status-response = empty-queue / nonempty-queue 1005 empty-queue = "no-entries" LF 1006 nonempty-queue = printer-status LF *job 1007 printer-status = OK-status / error-status 1008 OK-status = printer-name SP "ready and printing" LF 1009 error-status = < implementation dependent status information > 1010 job = LF line-1 LF line-2 LF 1011 line-1 = owner ":" SP rank 1*SP "[job" job SP host "]" 1012 line-2 = file-name 1*SP document-size "bytes" 1013 ; jobs are in order of oldest to newest 1014 rank = "active" / "1st" / "2nd" / "3rd" / integer "th" 1015 ; job that is printing is "active" 1016 ; other values show position in the queue 1017 owner = 1018 job = 1*3DIGIT 1019 file-name = [ 1*DIGIT "copies of" SP ] 1020 ; truncated to 24 characters 1021 document-size = 1*DIGIT ;size of single copy of the document. 1023 11. Appendix C: Unsupported LPD functions 1025 The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper 1026 ignores them and the IPP-to-LPD mapper does not send them. 1028 LPD command 1029 name description 1031 C Class for banner page 1032 I Indent Printing 1033 S Symbolic link data 1034 T Title for pr 1035 W Width of output 1036 1 troff R font 1037 2 troff I font 1038 3 troff B font 1039 4 troff S font 1041 The follow LPD functions specify document-formats which have no IPP 1042 equivalent, unless someone registers them. The LPD-to-IPP mapper rejects 1043 jobs that request such a document format, and the IPP-to-LPD mapper does 1044 not send them. 1046 LPD command 1047 name description 1049 c Plot CIF file 1050 d Print DVI file 1051 g Plot file 1052 k reserved for Kerberized clients and servers 1053 n Print ditroff output file 1054 p Print file with 'pr' format 1055 r File to print with FORTRAN carriage control 1056 t Print troff output file 1057 v Print raster file 1058 z reserved for future use with the Palladium 1059 print system 1061 ISSUE: we may move some of these to the supported list.