idnits 2.17.1 draft-ietf-ipp-lpd-ipp-map-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 20) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 203 has weird spacing: '...ommands to IP...' == Line 227 has weird spacing: '...If the mapper...' == Line 245 has weird spacing: '...ate-Job opera...' == Line 252 has weird spacing: '...AY use the ...' == Line 260 has weird spacing: '... single data ...' == (28 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 (November 16, 1998) is 9293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Robert Herriot (editor) 3 Sun Microsystems, Inc. 4 draft-ietf-ipp-lpd-ipp-map-05.txt Tom Hastings 5 Xerox Corporation 6 Norm Jacobs 7 Sun Microsystems, Inc. 8 Jay Martin 9 Underscore, Inc. 10 November 16, 1998 12 Mapping between LPD and IPP Protocols 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Copyright (C)The Internet Society (1998). All Rights Reserved. 34 Abstract 36 This document is one of a set of documents, which together describe all 37 aspects of a new Internet Printing Protocol (IPP). IPP is an application 38 level protocol that can be used for distributed printing using Internet 39 tools and technologies. This document gives some advice to implementers 40 of gateways between IPP and LPD (Line Printer Daemon). This document 41 describes the mapping between (1) the commands and operands of the 'Line 42 Printer Daemon (LPD) Protocol' specified in RFC 1179 and (2) the 43 operations, operation attributes and job template attributes of the 44 Internet Printing Protocol/1.0 (IPP). One of the purposes of this 45 document is to compare the functionality of the two protocols. Another 46 purpose is to facilitate implementation of gateways between LPD and IPP. 48 WARNING: RFC 1179 was not on the IETF standards track. While RFC 1179 49 was intended to record existing practice, it fell short in some areas. 50 However, this specification maps between (1) the actual current practice 51 of RFC 1179 and (2) IPP. This document does not attempt to map the 52 numerous divergent extensions to the LPD protocol that have been made by 53 many implementers. 55 Jacobs, Martin Expires May 16, 1999 56 The full set of IPP documents includes: 58 Design Goals for an Internet Printing Protocol [ipp-req] 59 Rationale for the Structure and Model and Protocol for the Internet 60 Printing Protocol [ipp-rat] 61 Internet Printing Protocol/1.0: Model and Semantics [ipp mod] 62 Internet Printing Protocol/1.0: Encoding and Transport [ipp-pro] 63 Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] 64 Mapping between LPD and IPP Protocols (this document) 66 The document, 'Design Goals for an Internet Printing Protocol', takes a 67 broad look at distributed printing functionality, and it enumerates 68 real-life scenarios that help to clarify the features that need to be 69 included in a printing protocol for the Internet. It identifies 70 requirements for three types of users: end users, operators, and 71 administrators. It calls out a subset of end user requirements that are 72 satisfied in IPP/1.0. Operator and administrator requirements are out of 73 scope for version 1.0. 75 The document, 'Rationale for the Structure and Model and Protocol for 76 the Internet Printing Protocol', describes IPP from a high level view, 77 defines a roadmap for the various documents that form the suite of IPP 78 specifications, and gives background and rationale for the IETF working 79 group's major decisions. 81 The document, 'Internet Printing Protocol/1.0: Model and Semantics', 82 describes a simplified model with abstract objects, their attributes, 83 and their operations. It introduces a Printer and a Job object. The Job 84 object supports multiple documents per Job. It also addresses security, 85 internationalization, and directory issues. 87 The document, 'Internet Printing Protocol/1.0: Encoding and Transport', 88 is a formal mapping of the abstract operations and attributes defined in 89 the model document onto HTTP/1.1. It defines the encoding rules for a 90 new Internet media type called 'application/ipp'. 92 This document 'Internet Printing Protocol/1.0: Implementer's Guide', 93 gives advice to implementers of IPP clients and IPP objects. 95 Jacobs, Martin Expires May 16, 1999 96 TABLE OF CONTENTS 98 1. Introduction......................................................4 99 2. Terminology.......................................................4 100 3. Mapping from LPD Commands to IPP Operations.......................5 101 3.1 Print any waiting jobs..........................................5 102 3.2 Receive a printer job...........................................5 103 3.2.1 Abort job....................................................6 104 3.2.2 Receive control file.........................................7 105 3.2.3 Receive data file............................................7 106 3.3 Send queue state (short)........................................8 107 3.4 Send queue state (long).........................................9 108 3.5 Remove jobs....................................................11 109 4. Mapping of LPD Control File Lines to IPP Operation and Job Template 110 Attributes............................................................11 111 4.1 Required Job Functions.........................................12 112 4.2 Optional Job Functions.........................................13 113 4.3 Required Document Functions....................................13 114 4.4 Recommended Document Functions.................................14 115 5. Mapping from IPP operations to LPD commands......................14 116 5.1 Print-Job......................................................15 117 5.2 Print-URI......................................................16 118 5.3 Validate-Job...................................................16 119 5.4 Create-Job.....................................................16 120 5.5 Send-Document..................................................17 121 5.6 Send-URI.......................................................17 122 5.7 Cancel-Job.....................................................17 123 5.8 Get-Printer-Attributes.........................................17 124 5.9 Get-Job-Attributes.............................................18 125 5.10 Get-Jobs.....................................................19 126 6. Mapping of IPP Attributes to LPD Control File Lines..............19 127 6.1 Required Job Functions.........................................20 128 6.2 Optional Job Functions.........................................20 129 6.3 Required Document Functions....................................20 130 7. Security Considerations..........................................21 131 8. References.......................................................21 132 9. Author's Addresses...............................................23 133 10. Appendix A: ABNF Syntax for response of Send-queue-state (short).23 134 11. Appendix B: ABNF Syntax for response of Send-queue-state (long)..24 135 12. Appendix C: Unsupported LPD functions............................24 136 13. Appendix D: Full Copyright Statement.............................25 138 Jacobs, Martin Expires May 16, 1999 139 Mapping between the LPD and IPP Protocols 141 1. Introduction 143 The reader of this specification is expected to be familiar with the IPP 144 Model and Semantics specification [ipp-mod], the IPP Encoding and 145 Transport [ipp-pro], and the Line Printer Daemon (LPD) protocol 146 specification [rfc1179] as described in RFC 1179. 148 RFC 1179 was written in 1990 in an attempt to document existing LPD 149 protocol implementations. Since then, a number of undocumented 150 extensions have been made by vendors to support functionality specific 151 to their printing solutions. All of these extensions consist of 152 additional control file commands. This document does not address any of 153 these vendor extensions. Rather it addresses existing practice within 154 the context of the features described by RFC 1179. Deviations of 155 existing practice from RFC 1179 are so indicated. 157 Other LPD control file commands in RFC 1179 are obsolete. They are 158 intended to work on "text" only formats and are inappropriate for many 159 contemporary document formats that completely specify each page. This 160 document does not address the support of these obsolete features. 162 In the area of document formats, also known as page description 163 languages (PDL), RFC 1179 defines a fixed set with no capability for 164 extension. Consequently, some new PDL's are not supported, and some of 165 those that are supported are sufficiently unimportant now that they have 166 not been registered for use with the Printer MIB[rfc1759] and IPP[ipp- 167 mod] [ipp-pro], though they could be registered if desired. See the 168 Printer MIB specification [rfc1759] and/or the IPP Model specification 169 [ipp-mod] for instructions for registration of document-formats with 170 IANA. IANA lists the registered document-formats as "printer 171 languages". 173 This document addresses the protocol mapping for both directions: 174 mapping of the LPD protocol to the IPP protocol and mapping of the IPP 175 protocol to the LPD protocol. The former is called the "LPD-to-IPP 176 mapper" and the latter is called the "IPP-to-LPD mapper". 178 This document is an informational document that is not on the standards 179 track. It is intended to help implementers of gateways between IPP and 180 LPD. It also provides an example, which gives additional insight into 181 IPP. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [rfc2119]. 189 Jacobs, Martin Expires May 16, 1999 190 RFC 1179 uses the word "command" in two contexts: for over-the-wire 191 operations and for command file functions. This document SHALL use the 192 word "command" for the former and the phrase "functions" for the latter. 193 The syntax of the LPD commands is given using ABNF [rfc2234]. 195 The following tokens are used in order to make the syntax more readable: 197 LF stands for %x0A (linefeed) 198 SP stands for %x20. (space) 199 DIGIT stands for %x30-39 ("0" to "9") 201 3. Mapping from LPD Commands to IPP Operations 203 This section describes the mapping from LPD commands to IPP operations. 204 Each of the following sub-sections appear as sub-sections of section 5 205 of RFC 1179. 207 The following table summarizes the IPP operation that the mapper uses 208 when it receives an LPD command. Each section below gives more detail: 210 LPD command IPP operation 212 print-any-waiting-jobs ignore 213 receive-a-printer-job Print-Job or Create-Job/Send-Document 214 send queue state (short Get-Printer-Attributes and Get-Jobs 215 or long) 216 remove-jobs Cancel-Job 218 3.1 Print any waiting jobs 220 Command syntax: 222 print-waiting-jobs = %x01 printer-name LF 224 This command causes the LPD daemon check its queue and print any waiting 225 jobs. An IPP printer handles waiting jobs without such a nudge. 227 If the mapper receives this LPD command, it SHALL ignore it and send no 228 IPP operation. 230 3.2 Receive a printer job 232 Command syntax: 234 receive-job = %x02 printer-name LF 236 The control file and data files mentioned in the following paragraphs 237 are received via LPD sub-commands that follow this command. Their 238 mapping to IPP commands and attributes is described later in this 239 section. 241 The mapper maps the 'Receive a printer job' command to either: 243 Jacobs, Martin Expires May 16, 1999 244 @ the Print-Job operation which includes a single data file or 245 @ the Create-Job operation followed by one Send-Document 246 operation for each data file. 248 If the IPP printer supports both Create-Job and Send-Document, and if a 249 job consists of: 251 @ a single data file, the mapper SHOULD use the Print-Job 252 operation, but MAY use the Create-Job and Send-Document 253 operations. 254 @ more than one data file, the mapper SHALL use Create-Job 255 followed by one Send-Document for each received LPD data file. 257 If the IPP printer does not support both Create-Job and Send-Document, 258 and if a job consists of: 260 @ a single data file, the mapper SHALL use the PrintJob 261 operation. 262 @ more than one data file, the mapper SHALL submit each received 263 LPD data file as a separate Print-Job operation (thereby 264 converting a single LPD job into multiple IPP jobs). 266 If the mapper uses Create-Job and Send-Document, it MUST send the 267 Create-Job operation before it sends any Send-Document operations 268 whether the LPD control file, which supplies attributes for Create-Job, 269 arrives before or after all LPD data files. 271 NOTE: This specification does not specify how the mapper maps: the LPD 272 Printer-name operand to the IPP "printer-uri" operation attribute. 274 The following three sub-sections gives further details about the mapping 275 from LPD receive-a-printer-job sub-commands. Each of the following sub- 276 sections appear as sub-sections of section 6 of RFC 1179. 278 3.2.1 Abort job 280 Sub-command syntax: 282 abort-job = %x1 LF 284 This sub-command of receive-a-printer-job is intended to abort any job 285 transfer in process. 287 If the mapper receives this sub-command, it SHALL cancel the job that it 288 is in the process of transmitting. 290 If the mapper is in the process of sending a Print-Job or Create-Job 291 operation, it terminates the job either by closing the connection, or 292 performing the Cancel-Job operation with the job-uri that it received 293 from the Print-Job or Create-Job operation. 295 Jacobs, Martin Expires May 16, 1999 296 NOTE: This sub-command is implied if at any time the connection between 297 the LPD client and server is terminated before an entire print job has 298 been transferred via an LPD Receive-a-printer-job request. 300 3.2.2 Receive control file 302 Sub-command syntax: 304 receive-control-file = %x2 number-of-bytes SP name-of-control-file LF 305 number-of-bytes = 1*DIGIT 306 name-of-control-file = "cfA" job-number client-host-name 307 ; e.g. "cfA123woden" 308 job-number = 3DIGIT 309 client-host-name = 311 This sub-command is roughly equivalent to the IPP Create-Job operation. 313 The mapper SHALL use the contents of the received LPD control file to 314 create IPP operation attribute and job template attribute values to 315 transmit with the Print-Job or Create-Job operation. 317 3.2.3 Receive data file 319 Sub-command syntax: %x3 number-of-bytes-in-data-file Name-of-data-file 321 receive-data-file = %x03 number-of-bytes SP name-of-data-file LF 322 number-of-bytes = 1*DIGIT 323 name-of-data-file = "df" letter job-number client-host-name 324 ; e.g. "dfA123woden for the first file 325 letter = %x41-5A / %x61-7A ; "A" to "Z", "a" to "z" 326 ; first file is "A", 327 ; second "B", and 52nd file is "z" 328 job-number = 3DIGIT 329 client-host-name = 331 This sub-command is roughly equivalent to the IPP Send-Document 332 operation. 334 The mapper SHALL use the contents of the received LPD data file as the 335 data to transmit with the IPP Print-Job or Send-Document operation. 337 Although RFC-1179 alludes to a method for passing an unspecified 338 length data file by using an octet-count of zero, no implementations 339 support this feature. The mapper SHALL reject a job that has a value of 340 0 in the number-of-bytes field. 342 Jacobs, Martin Expires May 16, 1999 343 3.3 Send queue state (short) 345 Command syntax: 347 send-queue-short = %x03 printer-name *(SP(user-name / job-number)) LF 349 The mapper's response to this command includes information about the 350 printer and its jobs. RFC 1179 specifies neither the information nor the 351 format of its response. This document requires the mapper to follow 352 existing practice as specified in this document. 354 The mapper SHALL produce a response in the following format which 355 consists of a printer-status line optionally followed by a heading line, 356 and a list of jobs. This format is defined by examples below. Appendix A 357 contains the ABNF syntax. 359 For an printer with no jobs, the response starts in column 1 and is: 361 no entries 363 For a printer with jobs, an example of the response is: 365 killtree is ready and printing 366 Rank Owner Job Files Total Size 367 active fred 123 stuff 1204 bytes 368 1st smith 124 resume, foo 34576 bytes 369 2nd fred 125 more 99 bytes 370 3rd mary 126 mydoc 378 bytes 371 4th jones 127 statistics.ps 4567 bytes 372 5th fred 128 data.txt 9 bytes 374 The column numbers of above headings and job entries are: 376 | | | | | 377 01 08 19 35 63 379 The mapper SHALL produce each field above from the following IPP 380 attribute: 382 LPD field IPP attribute special conversion details 384 printer- printer-state and For a printer-state of idle or 385 status printer-state-reasons processing, the mapper SHALL use 386 the formats above. For stopped, 387 the mapper SHALL use printer- 388 state-reasons to produce an 389 unspecified format for the error. 390 rank number-of- the mapper SHALL the format above 391 intervening-jobs 392 owner job-originating-user- unspecified conversion; job- 393 name originating-user-name may be the 394 mapper's user-name 395 job job-id the mapper shall use the job-id 397 Jacobs, Martin Expires May 16, 1999 398 LPD field IPP attribute special conversion details 400 files document-name the mapper shall create a comma 401 separated list of the document- 402 names and then truncate this list 403 to the first 24 characters 404 total- job-k- the mapper shall multiple the 405 size octets*copies*1024 value of job-k-octets by 1024 and 406 by the value of the "copies" 407 attribute. 409 A mapper SHOULD use the job attribute number-of-intervening-jobs rather 410 than the job's position in a list of jobs to determine 'rank' because a 411 Printer may omit jobs that it wants to keep secret. If a printer doesn't 412 support the job attribute number-of-intervening-jobs, a mapper MAY use 413 the job's position. 415 Note: a Printer may set the value of job-originating-user-name to the 416 authenticated user or to the value of "requesting-user-name", depending 417 on the implementation and configuration. For a gateway, the 418 authenticated user is the user-id of the gateway, but the "requesting- 419 user-name" may contain the name of the user who is the gateway's client. 421 In order to obtain the information specified above, The LPD-to-IPP 422 mapper SHALL use the Get-Printer-Attributes operation to get printer- 423 status and SHOULD use the Get-Jobs operation to get information about 424 all of the jobs. If the LPD command contains job-numbers or user-names, 425 the mapper MAY handle the filtering of the response. If the LPD command 426 contains job-numbers but no user-names, the mapper MAY use Get-Job- 427 Attributes on each converted job-number rather than Get-Jobs. If the LPD 428 command contains a single user-name but no job-numbers, the mapper MAY 429 use Get-Jobs with the my-jobs option if the server supports this option 430 and if the server allows the client to be a proxy for the LPD user. 432 NOTE: This specification does not define how the mapper maps the LPD 433 Printer-name operand to the IPP "printer-uri" operation attribute. 435 3.4 Send queue state (long) 437 Command syntax: 439 send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF 441 The mapper's response to this command includes information about the 442 printer and its jobs. RFC 1179 specifies neither the information nor the 443 format of its response. This document requires the mapper to follow 444 existing practice as specified in this document. 446 The mapper SHALL produce a response in the following format which 447 consists of a printer-status line optionally followed a list of jobs, 448 where each job consists of a blank line, a description line, and one 450 Jacobs, Martin Expires May 16, 1999 451 line for each file. The description line contains the user-name, rank, 452 job-number and host. This format is defined by examples below. Appendix 453 B contain the ABNF syntax. 455 For an printer with no jobs the response is: 457 no entries 459 For a printer with jobs, an example of the response is: 461 killtree is ready and printing 463 fred: active [job 123 tiger] 464 2 copies of stuff 602 bytes 466 smith: 1st [job 124 snail] 467 2 copies of resume 7088 bytes 468 2 copies of foo 10200 bytes 470 fred: 2nd [job 125 tiger] 471 more 99 bytes 473 The column numbers of above headings and job entries are: 475 | | | 476 01 09 41 478 Although the format of the long form is different from the format of the 479 short form, their fields are identical except for a) the copies and host 480 fields which are only in the long form, and b) the "size" field 481 contains the single copy size of each file. Thus the sum of the file 482 sizes in the "size" field times the value of the "copies" field 483 produces the value for the "Total Size" field in the short form. For 484 fields other than the host and copies fields, see the preceding section. 485 For the host field see the table below. 487 LPD field IPP attribute special conversion details 489 host unspecified conversion; job- 490 originating-host may be the 491 mapper's host 492 copies copies the mapper shall assume the 493 value of copies precedes the 494 string "copies of "; otherwise, 495 the value of copies is 1. 497 NOTE: This specification does not define how the mapper maps the LPD 498 Printer-name operand to the IPP printer-uri operation attribute. 500 Jacobs, Martin Expires May 16, 1999 501 3.5 Remove jobs 503 Command syntax: 505 remove-jobs = %x05 printer-name SP agent 506 *(SP(user-name / job-number)) LF 508 The agent operand is the user-name of the user initiating the remove- 509 jobs command. The special user-name 'root' indicates a privileged user 510 who can remove jobs whose user-name differs from the agent.. 512 The mapper SHALL issue one Cancel-Job operation for each job referenced 513 by the remove-jobs command. Each job-number in the remove-jobs command 514 references a single job. Each user-name in the remove-jobs command 515 implicitly references all jobs owned by the specified user. The active 516 job is implicitly referenced when the remove-jobs command contains 517 neither job-numbers nor user-names. The mapper MAY use Get-Jobs to 518 determine the job-uri of implicitly referenced jobs. 520 The mapper SHALL not use the agent name of 'root' when end-users cancel 521 their own jobs. Violation of this rule creates a potential security 522 violation, and it may cause the printer to issue a notification that 523 misleads a user into thinking that some other person canceled the job. 525 If the agent of a remove-jobs command for a job J is the same as the 526 user name specified with the 'P' function in the control file for job J, 527 then the mapper SHALL ensure that the initiator of the Cancel-Job 528 command for job J is the same as job-originating-user for job J. 530 Note: This requirement means that a mapper must be consistent in who the 531 receiver perceives as the initiator of IPP operations. The mapper either 532 acts as itself or acts on behalf of another user. The latter is 533 preferable if it is possible. This consistency is necessary between 534 Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but 535 it is also desirable for other operations. For example, Get-Jobs may 536 give more information about job submitted by the initiator of this 537 operation. 539 NOTE: This specification does not define how the mapper maps: (1) the 540 LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to 541 the IPP "job-uri". 543 NOTE: This specification does not specify how the mapper maps the LPD 544 user-name to the IPP job-originating-user because the mapper may use its 545 own user-name with jobs. 547 4. Mapping of LPD Control File Lines to IPP Operation and Job Template 548 Attributes 550 This section describes the mapping from LPD control file lines (called 551 'functions') to IPP operation attributes and job template attributes. 552 The mapper receives the control file lines via the LPD receive-control- 554 Jacobs, Martin Expires May 16, 1999 555 file sub-command.. Each of the LPD functions appear as sub-sections of 556 section 7 of RFC 1179. 558 In LPD control file lines, the text operands have a maximum length of 31 559 or 99 while IPP operation attribute and job template attribute values 560 have a maximum of 255 or 1023 octets, depending on the attribute syntax. 561 Therefore, no data is lost. 563 The mapper converts each supported LPD function to its corresponding IPP 564 operation or job template attribute as defined by tables in the 565 subsections that follow. These subsections group functions according to 566 whether they are: 568 @ required with a job, 569 @ optional with a job 570 @ required with each document. 572 In the tables below, each LPD value is given a name, such as 'h'. If an 573 IPP value uses the LPD value, then the IPP value column contains the LPD 574 name, such as 'h' to denote this. Otherwise, the IPP value column 575 specifies the literal value. 577 4.1 Required Job Functions 579 The following LPD functions MUST be in a received LPD job. The mapper 580 SHALL receive each of the following LPD functions and SHALL include the 581 information as a operation or job template attribute with each IPP job. 582 The functions SHOULD be in the order 'H', 'P' and they SHOULD be the 583 first two functions in the control file, but they MAY be anywhere in the 584 control file and in any order: 586 LPD function IPP 587 name value description name value 589 H h Originating Host h (in security layer) 590 P u User identification requesting- u (and in security 591 user-name layer) 592 none ipp- 'true' 593 attribute- 594 fidelity 596 A mapper MAY sen. its own host rather than the client's host, and a 597 mapper MAY send its own user-name as user identification rather than the 598 client user. But in any case, the values sent SHALL be compatible with 599 the Cancel-Job operation. The IPP operation MAY have no way to specify 600 an originating host-name. 602 The mapper SHALL include ipp-attribute-fidelity = true so that it 603 doesn't have to determine which attributes a printer supports. 605 Jacobs, Martin Expires May 16, 1999 606 4.2 Optional Job Functions 608 The following LPD functions MAY be present in a received job. These 609 function SHOULD follow the required job functions and precede the 610 document functions, but they MAY be anywhere in the control file. 612 If the mapper receives such an LPD function, the mapper SHALL include 613 the corresponding IPP attribute with the value converted as specified in 614 the table below. If the mapper does not receive such an LPD attribute, 615 the mapper SHALL NOT include the corresponding IPP attribute, except the 616 'L' LPD function whose absence has a special meaning as noted in the 617 table. 619 LPD function IPP 620 name value description name value 622 J j Job name for job-name j 623 banner page 624 L l Print banner page job-sheets 'standard' if 'L' is 625 present 626 'none' if 'L' is present 627 M m Mail When Printed IPP has no notification 628 mechanism. To support 629 this LPD feature, the 630 gateway must poll using 631 the Get-Job-Attributes 632 operation. 633 . 635 4.3 Required Document Functions 637 The mapper SHALL receive one set of the required document functions with 638 each copy of a document, and SHALL include the converted information as 639 operation or job template attributes with each IPP document. 641 If the control file contains required and recommended document 642 functions, the required functions SHOULD precede the recommended ones 643 and if the job contains multiple documents, all the functions for each 644 document are grouped together as shown in the example of section 6.3 645 "Required Document Functions". However, the document functions MAY be in 646 any order. 648 LPD function IPP 649 name valu description name value 650 e 652 f fff Print formatted document-format 'application/octet- 653 file stream' 654 l fff Print file leaving document-format 'application/octet- 655 control characters stream' 657 Jacobs, Martin Expires May 16, 1999 659 LPD function (cont.) IPP 660 o fff Print Postscript document-format 'application/PostScri 661 output file pt' 662 copies see note 664 Note: In practice, the 'f' LPD function is often overloaded. It is often 665 used with any format of document data including PostScript and PCL data. 667 Note: In practice, the 'l' LPD function is often used as a rough 668 equivalent to the 'f' function. 670 Note: When RFC 1179 was written, no implementation supported the 'o' 671 function; instead 'f' was used for PostScript. Windows NT now sends 'o' 672 function for a PostScript file. 674 Note: the value 'fff' of the 'f', 'l' and 'o' functions is the name of 675 the data file as transferred, e.g. "dfA123woden". 677 If the mapper receives any other lower case letter, the mapper SHALL 678 reject the job because the document contains a format that the mapper 679 does not support. 681 The mapper determines the number of copies by counting the number of 682 occurrences of each 'fff' file with one of the lower-case functions 683 above. For example, if 'f dfA123woden' occurs 4 times, then copies has a 684 value of 4. Although the LPD protocol allows the value of copies to be 685 different for each document, the commands and the receiving print 686 systems don't support this. 688 4.4 Recommended Document Functions 690 The mapper SHOULD receive one set of the recommended document functions 691 with each document, and SHOULD include the converted information as an 692 operation or job template attribute with each IPP document. The 693 functions SHOULD be received in the order 'U' and 'N', but they MAY 694 arrive in any order. 696 LPD function IPP 697 name value description name value 699 U fff ignored 700 N n Name of source file document-name n 702 Note: the value 'fff' of the 'U' function is the name of the data file 703 as transferred, e.g. "dfA123woden". 705 5. Mapping from IPP operations to LPD commands 707 If the IPP-to-LPD mapper receives an IPP operation, the following table 708 summarizes the LPD command that it uses. Each section below gives the 710 Jacobs, Martin Expires May 16, 1999 711 detail. Each of the following sub-sections appear as sub-sections of 712 section 3 in the document "Internet Printing Protocol/1.0: Model and 713 Semantics" [ipp-mod]. 715 IPP operation LPD command 717 Print-Job or Print-URI or receive-a-printer-job 718 Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs 719 Validate-Job implemented by the mapper 720 Cancel-Job remove-jobs 721 Get-Printer-Attributes, Get-Job- send queue state (short or long) 722 Attributes or Get-Jobs 724 5.1 Print-Job 726 The mapper SHALL send the following commands in the order listed below: 728 @ receive-a-printer-job command 729 @ both receive-control-file sub-command and receive-data-file 730 sub-command 731 (unspecified order, see Note below) 732 @ print-any-waiting-jobs command, 733 except that if the mapper is sending a sequence of receive-a- 734 printer-job commands, it MAY omit sending print-any-waiting- 735 jobs after any receive-a printer-job command that is neither 736 the first nor last command in this sequence 738 Note: it is recommended that the order of the receive-control-file sub- 739 command and the receive-data-file sub-command be configurable because 740 either order fails for some print systems. Some print systems assume 741 that the control file follows all data files and start printing 742 immediately on receipt of the control file. When such a print system 743 tries to print a data file that has not arrived, it produces an error. 744 Other print systems assume that the control file arrives before the data 745 files and start printing when the first data file arrives. Such a system 746 ignores the control information, such as banner page or copies. 748 NOTE: This specification does not define the mapping between the IPP 749 printer-uri and the LPD printer-name. 751 The mapper SHALL send the IPP operation attributes and job template 752 attributes received from the operation to the LPD printer by using the 753 LPD receive-control-file sub-command. The mapper SHALL create the LPD 754 job-number for use in the control file name, but the receiving printer 755 MAY, in some circumstances, assign a different job-number to the job. 756 The mapper SHALL create the IPP job-id and IPP job-uri returned in the 757 Print-Job response. 759 NOTE: This specification does not specify how the mapper determines the 760 LPD job-number, the IPP job-id or the IPP job-uri of a job that it 761 creates nor does it specify the relationship between the IPP job-uri, 762 IPP the job-id and the LPD job-number, both of which the mapper creates. 763 However, it is likely that the mapper will use the same integer value 765 Jacobs, Martin Expires May 16, 1999 766 for both the LPD job-number and the IPP job-id, and that the IPP Job-uri 767 is the printer's URI with the job-id concatenated on the end. 769 The mapper SHALL send data received in the IPP operation to the LPD 770 printer by using the LPD receive-data-file sub-command. The mapper SHALL 771 specify the exact number of bytes being transmitted in the number-of- 772 bytes field of the receive-data-file sub-command. It SHALL NOT use a 773 value of 0 in this field. 775 If the mapper, while it is transmitting a receive-a-printer-job command 776 or sub-command, either detects that its IPP connection has closed or 777 receives a Cancel-Job operation, the mapper SHALL terminate the LPD job 778 either with the abort sub-command or the remove-jobs command. 780 This document does not address error code conversion. 782 5.2 Print-URI 784 The mapper SHALL handle this operation in the same way as a Print-Job 785 operation except that it SHALL obtain data referenced by the "document- 786 uri" operation attribute and SHALL then treat that data as if it had 787 been received via a Print-Job operation. 789 5.3 Validate-Job 791 The mapper SHALL perform this operation directly. Because LPD supports 792 very few attributes, this operation doesn't have much to check. 794 5.4 Create-Job 796 The mapper SHALL handle this operation like Print-Job, except: 798 @ the mapper SHALL send the control file after it has received 799 the last Send-Document or Send-URI operation because the 800 control file contains all the document-name and document- 801 format values specified in the Send-Document and Send-URI 802 operations. 803 @ the mapper SHALL perform one receive-data-file sub-command for 804 each Send-Document or Send-URI operation received and in the 805 same order received. 806 @ the mapper SHALL send the control file either before all data 807 files or after all data files. 808 (See the note in the section on Print-Job about the dilemma of 809 sending the control file either before or after the data 810 files. 812 Jacobs, Martin Expires May 16, 1999 814 5.5 Send-Document 816 The mapper performs a receive-data-file sub-command on the received 817 data. See the preceding section 5.4 "Create-Job" for the details. 819 5.6 Send-URI 821 The mapper SHALL obtain the data referenced by the "document-uri" 822 operation attribute, and SHALL then treat that data as if it had been 823 received via a Send-Document operation. See the preceding section 5.5 824 "Send-Document" for the details. 826 5.7 Cancel-Job 828 The mapper SHALL perform a remove-jobs command with the following 829 operation attributes: 831 @ the printer is the one to which the job was submitted, that is 832 the IPP printer-uri is mapped to an LPD printer-name by the 833 same mechanism as for all commands 834 @ the agent is the authenticated user-name of the IPP client 835 @ the job-number is the job-id returned by the Print-Job 836 command, that is, the LPD job-number has the same value as the 837 IPP job-id for likely implementations 839 5.8 Get-Printer-Attributes 841 LPD severely limits the set of attributes that the mapper is able to 842 return in its response for this operation. The mapper SHALL support, at 843 most, the following printer attributes: 845 @ printer-state 846 @ printer-state-reasons 848 The mapper uses either the long or short form of the "send queue state" 849 command. 851 The mapper SHALL assume that the LPD response that it receives has the 852 format and information specified in section 3.3 " 854 Jacobs, Martin Expires May 16, 1999 855 Send queue state (short)" and section 3.4 "Send queue state (long)". 856 The mapper SHALL determine the value of each requested attribute by 857 using the inverse of the mapping specified in the two aforementioned 858 sections. 860 Note: the mapper can determine the response from the printer-status line 861 without examining the rest of the LPD response. 863 5.9 Get-Job-Attributes 865 LPD severely limits the set of attributes that the mapper is able to 866 return in its response for this operation. The mapper SHALL support, at 867 most, the following job attributes: 869 @ number-of-intervening-jobs 870 @ job-originating-user-name 871 @ job-id 872 @ document-name 873 @ job-k-octets 874 @ copies 876 The mapper uses either the long or short form of the "send queue state" 877 command. If it receives a request for the "job-k-octets" or "copies" 878 and supports the attribute it SHALL use the long form; otherwise, it 879 SHALL use the short form. 881 Note: the value of job-k-octets is the value in the short form divided 882 by the number of "copies" which is on the long form only. Its value can 883 also be determined by adding the "size" field values for each document 884 in the job in the long form. 886 The mapper SHALL assume that the LPD response that it receives has the 887 format and information specified in section 3.3 " 889 Jacobs, Martin Expires May 16, 1999 890 Send queue state (short)" and section 3.4 "Send queue state (long)". 891 The mapper SHALL determine the value of each requested attribute by 892 using the inverse of the mapping specified in the two aforementioned 893 sections. 895 Note: when the mapper uses the LPD short form, it can determine the 896 response from the single LPD line that pertains to the job specified by 897 the Get-Job-Attributes operation. 899 Note: the mapper can use its correspondence between the IPP job-id, job- 900 uri and the LPD job-number. 902 5.10 Get-Jobs 904 The mapper SHALL perform this operation in the same way as Get-Job- 905 Attributes except that the mapper converts all the LPD job-lines, and 906 the IPP response contains one job object for each job-line in the LPD 907 response. 909 6. Mapping of IPP Attributes to LPD Control File Lines 911 This section describes the mapping from IPP operation attributes and job 912 template attributes to LPD control file lines (called 'functions'). The 913 mapper receives the IPP operation attributes and job template atributes 914 via the IPP operation. Each of the IPP operation attributes and job 915 template attributes appear as sub-sections of section 3 and 4.2 in the 916 IPP model document [ipp-mod]. 918 In the context of LPD control file lines, the text operands have a 919 maximum length of 31 or 99 while IPP operation attributes and job 920 template attributes have a maximum of 255 or 1023 octets, depending on 921 the attribute syntax. Therefore, there may be some data loss if the IPP 922 operation attribute and job template attribute values exceed the maximum 923 length of the LPD equivalent operands. 925 The mapper converts each supported IPP operation attribute and job 926 template attribute to its corresponding LPD function as defined by 927 tables in the subsections that follow. These subsections group functions 928 according to whether they are: 930 @ required with a job, 931 @ optional with a job 932 @ required with each document. 934 In the tables below, each IPP value is given a name, such as 'h'. If an 935 LPD value uses the IPP value, then the LPD value column contains the IPP 936 name, such as 'h' to denote this. Otherwise, the LPD value column 937 specifies the literal value. 939 Jacobs, Martin Expires May 16, 1999 940 6.1 Required Job Functions 942 The mapper SHALL include the following LPD functions with each job, and 943 they SHALL have the specified value. They SHALL be the first functions 944 in the control file and they SHALL be in the order "H" and then "P". 946 IPP LPD function 947 name value name value description 949 (perhaps in security h H gateway host Originating Host 950 layer) 951 requesting-user-name u P u User identification 952 and in the security 953 layer 955 A mapper SHALL sends its own host rather than the client's host, because 956 some LPD systems require that it be the same as the host from which the 957 remove-jobs command comes. A mapper MAY send its own user name as user 958 identification rather than the client user. But in any case, the values 959 sent SHALL be compatible with the LPD remove-jobs operation. 961 6.2 Optional Job Functions 963 The mapper MAY include the following LPD functions with each job. They 964 SHALL have the specified value if they are sent. These functions, if 965 present, SHALL follow the require job functions, and they SHALL precede 966 the required document functions. 968 IPP attribute LPD function 969 name value nam value description 970 e 972 job-name j J j Job name for banner 973 page 974 job-sheets 'standard' L u Print banner page 975 job-sheets 'none' omit 'L' function 976 Note: 'L' has special meaning when it is omitted. If 'J' is omitted, 977 some undefined behavior occurs with respect to the banner page. 979 6.3 Required Document Functions 981 The mapper SHALL include one set of the following LPD functions with 982 each document, and they SHALL have the specified values. For each 983 document, the order of the functions SHALL be 'f', 'U' and then 'N', 984 where 'f' is replicated once for each copy. 986 IPP attribute LPD function 988 Jacobs, Martin Expires May 16, 1999 989 name value name value description 991 document- 'application/octet- f fff Print formatted file 992 format stream' or 993 'application/PostScrip 994 t' 995 copies c replicate 'f' 'c' 996 times 997 none U fff Unlink data file 998 document- n N n Name of source file 999 name 1001 Note: the value 'fff' of the 'f' and 'U' functions is the name of the 1002 data file as transferred, e.g. "dfA123woden". 1004 Note: the mapper SHALL not send the 'o' function 1006 ISSUE: should we register DVI, troff or ditroff? 1008 If the mapper receives no "ipp-attribute-fidelitybest-effort" or it has 1009 a value of false, then the mapper SHALL reject the job if it specifies 1010 attributes or attribute values that are not among those supported in the 1011 above tables. 1013 Below is an example of the minimal control file for a job with three 1014 copies of two files 'foo' and 'bar': 1016 H tiger 1017 P jones 1018 f dfA123woden 1019 f dfA123woden 1020 f dfA123woden 1021 U dfA123woden 1022 N foo 1023 f dfB123woden 1024 f dfB123woden 1025 f dfB123woden 1026 U dfB123woden 1027 N bar 1029 7. Security Considerations 1031 There are no security issues beyond those covered in the IPP Encoding 1032 and Transport document [ipp-pro], the IPP model document [ipp-mod] and 1033 the LPD document [rfc1179]. 1035 8. References 1037 [ipp-iig] Hasting, Tom, et al., "Internet Printing Protocol/1.0: 1038 Implementer's Guide", draft-ietf-ipp-implementers-guide-00.txt, 1039 November 1998 1041 Jacobs, Martin Expires May 16, 1999 1043 [ipp-mod] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1044 "Internet Printing Protocol/1.0: Model and Semantics", , November, 1998. 1047 [ipp-pro] Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet 1048 Printing Protocol/1.0: Encoding and Transport", draft-ietf-ipp- 1049 pro-07.txt, November 1998. 1051 [ipp-rat] Zilles, S., "Rationale for the Structure and Model and 1052 Protocol for the Internet Printing Protocol", draft-ietf-ipp- 1053 rat-04.txt, November 1998. 1055 [ipp-req] Wright, D., "Design Goals for an Internet Printing 1056 Protocol", draft-ietf-ipp-req-03.txt, November, 1998. 1058 [rfc1179] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, 1059 August 1990. 1061 [rfc1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and 1062 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 1064 [rfc2119] S. Bradner, "Key words for use in RFCs to Indicate 1065 Requirement Levels", RFC 2119, March 1997 1067 [rec2234] D. Crocker et al., "Augmented BNF for Syntax Specifications: 1068 ABNF", RFC 2234, November 1997. 1070 Jacobs, Martin Expires May 16, 1999 1072 9. Author's Addresses 1074 Robert Herriot (editor) Norm Jacobs 1075 Sun Microsystems Inc. Sun Microsystems Inc. 1076 901 San Antonio.Road., MPK-17 1430 Owl Ridge Rd. 1077 Mountain View, CA 94043 Colorado Springs, CO 80919 1079 Phone: 650-786-8995 Phone: 719-532-9927 1080 Fax: 650-786-7077 Fax: 719-535-0956 1081 Email: robert.herriot@eng.sun.com Email: 1082 Norm.Jacobs@Central.sun.com 1084 Thomas N. Hastings Jay Martin 1085 Xerox Corporation Underscore, Inc. 1086 701 S. Aviation Blvd., ESAE-231 41-C Sagamore Park Road 1087 El Segundo, CA 90245 Hudson, NH 03051-4915 1089 Phone: 310-333-6413 Phone: 603-889-7000 1090 Fax: 310-333-5514 Fax: 603-889-2699 1091 EMail: hastings@cp10.es.xerox.com Email: jkm@underscore.com 1093 10. Appendix A: ABNF Syntax for response of Send-queue-state (short) 1095 The syntax in ABNF for the response to the LPD command 'send-queue-state 1096 (long)' is: 1098 status-response = empty-queue / nonempty-queue 1099 empty-queue = "no-entries" LF 1100 nonempty-queue = printer-status LF heading LF *(job LF) 1101 printer-status = OK-status / error-status 1102 OK-status = printer-name SP "ready and printing" LF 1103 error-status = < implementation dependent status information > 1104 heading = "Rank" 3SP "Owner" 6SP "Job" 13SP "Files" 1105 23SP "Total Size" LF 1106 ; the column headings and their values below begin 1107 at the columns 1108 ; 1, 8, 19, 35 and 63 1109 job = rank *SP owner *SP job *SP files *SP total-size "bytes" 1110 ; jobs are in order of oldest to newest 1111 rank = "active" / "1st" / "2nd" / "3rd" / integer "th" 1112 ; job that is printing is "active" 1113 ; other values show position in the queue 1114 owner = 1115 job = 1*3DIGIT ; job-number 1116 files = *( "," ) ; truncated to 24 characters 1117 total-size = 1*DIGIT ; combined size in bytes of all documents 1119 Jacobs, Martin Expires May 16, 1999 1121 11. Appendix B: ABNF Syntax for response of Send-queue-state (long) 1123 The syntax in ABNF for the response to the LPD command 'send-queue-state 1124 (long)' is: 1126 status-response = empty-queue / nonempty-queue 1127 empty-queue = "no-entries" LF 1128 nonempty-queue = printer-status LF *job 1129 printer-status = OK-status / error-status 1130 OK-status = printer-name SP "ready and printing" LF 1131 error-status = < implementation dependent status information > 1132 job = LF line-1 LF line-2 LF 1133 line-1 = owner ":" SP rank 1*SP "[job" job SP host "]" 1134 line-2 = file-name 1*SP document-size "bytes" 1135 ; jobs are in order of oldest to newest 1136 rank = "active" / "1st" / "2nd" / "3rd" / integer "th" 1137 ; job that is printing is "active" 1138 ; other values show position in the queue 1139 owner = 1140 job = 1*3DIGIT 1141 file-name = [ 1*DIGIT "copies of" SP ] 1142 ; truncated to 24 characters 1143 document-size = 1*DIGIT ;size of single copy of the document. 1145 12. Appendix C: Unsupported LPD functions 1147 The follow LPD functions have no IPP equivalent. The LPD-to-IPP mapper 1148 ignores them and the IPP-to-LPD mapper does not send them. 1150 LPD command 1151 name description 1153 C Class for banner page 1154 I Indent Printing 1155 H Host of client 1156 M Mail when printed 1157 S Symbolic link data 1158 T Title for pr 1159 W Width of output 1160 1 troff R font 1161 2 troff I font 1162 3 troff B font 1163 4 troff S font 1165 The follow LPD functions specify document-formats which have no IPP 1166 equivalent, unless someone registers them. The LPD-to-IPP mapper rejects 1167 jobs that request such a document format, and the IPP-to-LPD mapper does 1168 not send them. 1170 Jacobs, Martin Expires May 16, 1999 1171 LPD command 1172 name description 1174 c Plot CIF file 1175 d Print DVI file 1176 g Plot file 1177 k reserved for Kerberized clients and servers 1178 n Print ditroff output file 1179 p Print file with 'pr' format 1180 r File to print with FORTRAN carriage control 1181 t Print troff output file 1182 v Print raster file 1183 z reserved for future use with the Palladium 1184 print system 1186 13. Appendix D: Full Copyright Statement 1188 Copyright (C)The Internet Society (1997). All Rights Reserved 1190 This document and translations of it may be copied and furnished to 1191 others, and derivative works that comment on or otherwise explain it or 1192 assist in its implementation may be prepared, copied, published and 1193 distributed, in whole or in part, without restriction of any kind, 1194 provided that the above copyright notice and this paragraph are included 1195 on all such copies and derivative works. However, this document itself 1196 may not be modified in any way, such as by removing the copyright notice 1197 or references to the Internet Society or other Internet organizations, 1198 except as needed for the purpose of developing Internet standards in 1199 which case the procedures for copyrights defined in the Internet 1200 Standards process must be followed, or as required to translate it into 1201 languages other than English. 1203 The limited permissions granted above are perpetual and will not be 1204 revoked by the Internet Society or its successors or assigns. 1206 This document and the information contained herein is provided on an "AS 1207 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1208 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1209 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1210 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1211 FITNESS FOR A PARTICULAR PURPOSE. 1213 Jacobs, Martin Expires May 16, 1999