idnits 2.17.1 draft-ietf-ipp-lpd-ipp-map-00.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-19) 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 12 longer pages, the longest (page 1) being 61 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 317 has weird spacing: '...ued for the j...' -- 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 13, 1998) is 9593 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 499 looks like a reference -- Missing reference section? '2' on line 503 looks like a reference -- Missing reference section? '3' on line 507 looks like a reference -- Missing reference section? '4' on line 510 looks like a reference -- Missing reference section? '6' on line 516 looks like a reference -- Missing reference section? '5' on line 513 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Tom Hasting 2 Xerox Corporation 3 Bob Herriot 4 Sun Microsystems, Inc. 5 Norm Jacobs 6 Sun Microsystems, Inc. 7 Jay Martin 8 Underscore, Inc. 9 July 13, 1997 11 Mapping between LPD and IPP Protocols 13 15 Expires Jan 13, 1998 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 To learn the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Abstract 38 This Internet-Draft specifies the mapping between (1) the commands 39 and operands of the "Line Printer Daemon (LPD) Protocol" specified 40 in RFC 1179 and (2) the operations and parameters of the Internet 41 Printing Protocol (IPP). One of the purposes of this document is 42 to compare the functionality of the two protocols. Another purpose 43 is to facilitate implementation of gateways between LPD and IPP. 45 WARNING: RFC 1179 was not on standards track. While RFC 1179 was 46 intended to record existing practice, in some areas it fell short. 47 However, this specification maps between (1) the actual current 48 practice of RFC 1179 and (2) IPP. This document does not attempt 49 to map the numerous divergent extensions to the LPD protocol that 50 have been made by many implementors. 52 Mapping between LPD and IPP Protocols June 27, 1997 54 TABLE OF CONTENTS 56 1. INTRODUCTION........................................................3 58 2. TERMINOLOGY.........................................................3 60 3. MAPPING BETWEEN LPD COMMANDS AND IPP OPERATIONS....................3 62 3.1 Print any waiting jobs ...........................................4 64 3.2 Receive a printer job ............................................4 66 3.3 Send queue state (short) .........................................5 68 3.4 Send queue state (long) ..........................................5 70 3.5 05 - Remove jobs .................................................6 72 4. MAPPING BETWEEN LPD SUB-COMMANDS AND IPP OPERATIONS.................6 74 4.1 01 - Abort job () ................................................6 76 4.2 02 - Receive control file ........................................7 78 4.3 03 - Receive data file ...........................................7 80 5. MAPPING OF LPD CONTROL FILE LINES TO IPP OPERATION INPUT PARAMETERS.7 82 6. BIBLIOGRAPHY.......................................................10 84 7. AUTHOR'S ADDRESSES.................................................10 85 Mapping between LPD and IPP Protocols June 27, 1997 87 Mapping between the LPD and IPP Protocols 89 1. Introduction 91 The reader of this specification is expected to be familiar with the IPP 92 Model and Semantics specification [1], the IPP Protocol specification 93 [2], and the Line Printer Daemon (LPD) protocol specification [3] as 94 described in RFC 1179. 96 RFC 1179 was written in 1990 in an attempt to document existing LPD 97 protocol implementations. Since then, a number of undocumented 98 extensions have been made by vendors to support functionality specific 99 to their printing solutions. All of these extensions consist of 100 additional control file directives. This document does not address any 101 of these vendor extensions. Rather it addresses existing practice 102 within the context of the features described by RFC 1179. Deviations of 103 existing practice from RFC 1179 are so indicated. 105 In the area of document formats, also known as page description 106 languages (PDL), RFC 1179 defines a fixed set with no capability for 107 extension. Consequently, some new PDL's are not supported, and some of 108 those that are supported are sufficiently unimportant now that they have 109 not been registered for use with the Printer MIB[4] and IPP[1] [2], 110 though they could be registered if desired. See the Printer MIB 111 specification [4] and/or the IPP Model specification [1] for 112 instructions for registration of document-formats with IANA. IANA lists 113 the registered document-formats as "printer languages". 115 Other LPD commands are intended to work on "text" only formats and so 116 are inappropriate for many contemporary document formats that completely 117 specify each page. 119 This document addresses the protocol mapping for both directions: 120 mapping of the LPD protocol to the IPP protocol and mapping of the IPP 121 protocol to the LPD protocol. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [6]. 129 The syntax of the LPD commands is given using ABNF [6]. 131 The following tokens are used in order to make the syntax more readable: 132 LF stands for %x0A (linefeed) 133 Mapping between LPD and IPP Protocols June 27, 1997 135 SP stands for %x20. (space) 137 3. Mapping between LPD Commands and IPP Operations 139 This section describes the mapping between LPD on-the wire and IPP 140 operations. Each of the following sub-sections appear as sub-sections 141 of section 5 of RFC 1179. 143 3.1 Print any waiting jobs 145 Command syntax: %x01 Printer-queue-name LF 147 In LPD, this comment starts the daemon, if it isn't already running. 148 Such an equivalent operation is not provided in IPP, since the IPP 149 Printer is assumed to always be running, where as in LPD, the client 150 makes sure that the daemon is running using this command. 152 If an LPD-to-IPP mapper receives this LPD command, it SHALL ignore it 153 and send no IPP operation. 155 An IPP-to-LPD mapper SHALL send this LPD command after it has finished 156 sending all pending `Receive a printer job' commands. 158 3.2 Receive a printer job 160 Command syntax: %x02 Printer-queue-name LF 162 An LPD-to-IPP mapper SHALL map the 'Receive a printer job' command to 163 either: 165 . the Print-Job operation with a single data file or 167 . the Create-Job operation followed by a Send-Document operation 168 for each data file. 170 If a job consists of a single data file, the PrintJob operation is 171 RECOMMENDED. 173 If a job consists of more than one data file, Create Job followed by 174 Send-Document for each data file is REQUIRED. If the IPP Printer 175 doesn't support the Create-Job and Send-Document operations, the LPD-to- 176 IPP mapper SHALL submit each data file as a separate Print-Job operation 177 (thereby converting a single LPD job into multiple IPP jobs). 179 ISSUE: Ok that I changed so that the mapper shall break a multi-document 180 job into separate jobs, one IPP job for each LPD data file, instead of 181 error return? 182 Mapping between LPD and IPP Protocols June 27, 1997 184 NOTE: if Create-Job is used, it MUST precede the Send-Document operation 185 even if the LPD control file, which supplies attributes for Create-Job, 186 arrives after all documents. 188 An IPP-to-LPD mapper SHALL map the following IPP operations to this LPD 189 command: 191 . Print-Job 193 . Print-uri 195 . Create-Job followed by Send-Document or Send-URI for each 196 document 198 The mechanism for mapping between an LPD Printer-queue-name operand and 199 the IPP "printer-uri" parameter is not defined in this document. 201 ISSUE: error code conversion. 203 See the next section for the mapping of the LPD "second level commands" 204 to IPP input-parameters. 206 3.3 Send queue state (short) 208 Command syntax: %x03 Printer-queue-name *( SP ( User-Name / job-number) 209 ) 211 If the LPD command contains only the Printer-queue-name operand, the 212 LPD-to-IPP mapper SHALL use the Get-Attributes operation of the 213 corresponding IPP Printer to get printer-state information and the Get- 214 Jobs operation of the Printer to get information about all of the jobs. 215 With Get-Attributes, it SHALL request the "printer-state" and "printer- 216 state-reasons" attributes. With Get-Jobs, it SHALL request the "number- 217 of-intervening-jobs", "job-originating-user", "job-name", "document- 218 name" (or "document-uri"), and "job-k-octets". 220 NOTE: RFC 1179 does not specify what attributes are returned in 221 response to a 'Send queue state' (short) command, but leaves it up to 222 implementation. The IPP attributes specified in this specification 223 reflect existing practice. 225 NOTE: This specification does not specify how the LPD-to-IPP mapper 226 maps: (1) the LPD Printer-queue-name operand to the IPP "printer-uri" 227 parameter or (2) the LPD job-number operand to the IPP "job-uri" 228 parameter, since the format of these URIs is opaque in the IPP protocol 229 and is implementation-dependent. 231 Mapping between LPD and IPP Protocols June 27, 1997 233 If the LPD command contains one or more User-name operands, the LPD-to- 234 IPP mapper SHALL get all the jobs as above using the Get-Jobs operation 235 on the Printer and then do its own filtering on the returned value of 236 the "job-originating-user" attribute for each job. 238 If the LPD command contains only job-number operands, the LPD-to-IPP 239 mapper SHALL either (1) get all the jobs as above using the Get-Jobs 240 operation on the Printer and then do its own filtering or (2) get each 241 specified job individually using separate Get-Attributes operations 242 (multiple jobs may be requested in a single IPP connection with multiple 243 Get-Attribute operations, one for each job). 245 The IPP-to-LPD mapper shall use the long version of this command. See 246 that command. 248 3.4 Send queue state (long) 250 Command syntax: %x04 printer-name *( SP ( user-name / job-number) ) 252 Same mapping as the 'Send queue state' (short) command. The IPP client 253 supplies a longer list of requested attributes to the Get-Jobs or Get- 254 Attributes operations. 256 The LPD-to-IPP mapper should specify additional attributes than the ones 257 listed for the 'Send queue state' (short) command. 259 NOTE: RFC 1179 does not specify what attributes are returned in 260 response to a 'Send queue state' (short) command, but leaves it up to 261 implementation. 263 The IPP-to-LPD mapper shall use this command to get what attributes it 264 can from the LPD server. 266 3.5 05 - Remove jobs 268 Command syntax: %x05 Printer-queue-name SP agent *(SP (User-name / job- 269 number)) 271 The agent operand is the user-name of the user initiating the 'Remove 272 jobs' command. The special user-name 'root' indicates a privileged 273 user. 275 The LPD-to-IPP mapper shall map this command to the Cancel-Job 276 operation. 278 This command with the Printer-queue-name operand and one job-number 279 operand is the same as the IPP Cancel-Job operation when the client 280 supplies just the job URI. Multiple jobs may be canceled in IPP in a 281 Mapping between LPD and IPP Protocols June 27, 1997 283 single connection with multiple Cancel-Job operations. In IPP only a 284 privileged operator may cancel jobs belonging to another user. 286 NOTE: This specification does not specify how the LPD-to-IPP mapper 287 maps: (1) the LPD Printer-queue-name to the IPP "printer-uri" or (2) the 288 LPD job-number to the IPP "job-uri", since the format of these URIs is 289 opaque in the IPP protocol and is implementation-dependent. 291 There is no IPP equivalent for the LPD 'Remove jobs' command with just 292 the Printer-queue-name operand supplied, since IPP provides no way to 293 cancel the current job. 295 There is no IPP equivalent for the LPD 'Remove jobs' command with a 296 User-name operand supplied, since IPP provides no way to cancel a job 297 specified by user name. 299 The LPD-to-IPP mapper shall map a Cancel-Job operation to this command. 301 There are some major issues about setting the agent. 303 4. Mapping between LPD Sub-Commands and IPP Operations 305 This section describes the mapping between LPD sub-commands and IPP 306 operations. Each of the following sub-sections appear as sub-sections 307 of section 6 of RFC 1179. The operands of the sub-commands appear in 308 parens in the sub-headings 310 4.1 01 - Abort job () 312 Sub-command syntax: %x01 314 This sub-command is intended to abort any job transfer in process. If 315 an IPP Create-Job operation and/or a Send-Document operation were 316 performed on behalf of the receive job command that is being aborted, an 317 IPP Cancel-Job operation should be issued for the job URI that was 318 returned by the Printer on which the Create-Job operation was performed. 319 Also, any temporary files created while processing the 'Receive job 320 request' should be cleaned up, and the connection to the client should 321 be closed. Finally, this sub-command is implied if at any time the 322 connection between the LPD client and server is terminated before an 323 entire print job has been transferred via an LPD 'Receive job request'. 325 ISSUE: is IPP defined at this point to abort a job whose connection is 326 closed before the job has been fully received. If so, that is an 327 alternate and simpler way to abort the job. 329 Mapping between LPD and IPP Protocols June 27, 1997 331 4.2 02 - Receive control file 333 Sub-command syntax: %x02 Number-of-bytes-in-control-file, Name-of- 334 control-file 336 This sub-command is roughly equivalent to the IPP Create-Job operation. 337 Once the control file has been has been received, it's contents should 338 be translated, and an appropriate IPP Create-Job operation performed. 340 However, some information, such as Document-Name go in the Send-Document 341 operation. 343 4.3 03 - Receive data file 345 Sub-command syntax: %x03 Number-of-bytes-in-data-file Name-of-data-file 347 This sub-command is roughly equivalent to the IPP Send-Document 348 operation. If the control file has been previously received, and it's 349 corresponding IPP Create-Job operation performed, an IPP Send-Document 350 operation can be performed using the job URI returned by the IPP Create- 351 Job operation. 353 When performing the Send-Document operation, the size of the document 354 data MUST be specified. Unfortunately RFC-1179 alludes to a method for 355 passing an arbitrary length data file. This is described as being done 356 by using an octet-count of zero, however the description isn't complete, 357 and in practice, no implementations allow sending or receiving arbitrary 358 length data files. 360 5. Mapping of LPD control file lines to IPP Operation Input Parameters 362 This section describes the mapping from LPD control file lines to IPP 363 operation input parameters for the Print-Job, Create-Job, and Send- 364 Document operations. Each of the following sub-sections appear as sub- 365 sections of section 7 of RFC 1179. 367 ISSUE: somewhere, we need to map the LPD query format to IPP attributes. 369 In LPD text operands have a maximum length of 31 or 99 while IPP input 370 parameters have a maximum of 255 characters. Therefore, no data is lost 371 when mapping from LPD to IPP. However, when mapping from IPP to LPD, 372 there may be some data loss if the IPP parameters exceed the maximum 373 length of the LPD equivalent operands. 375 In the following table, IPP input parameter names are indicated in 376 double quotes (") and input parameter values are indicated in single 377 quotes ('). Values of the IPP "document-format" attribute that could be 378 registered, but are not currently, are indicated with "**". 380 Mapping between LPD and IPP Protocols June 27, 1997 382 Where there is a one-to-one mapping, both directions are specified. 383 Where IPP has none, the LPD-to-IPP the attribute is ignored, and in the 384 IPP-to-LPD the LPD feature is left unspecified. 386 LPD command Equivalent IPP input parameter(s) 388 C Class for banner None. 389 page 391 H Originating Host "job-originating-host" 393 I Indent Printing None. 395 J Job name for banner "job-name" 396 page 398 L Print banner page "job-sheets" = any but 'none' 399 Absence of an `L' directive 400 indicates that ``job-sheets=none'' 401 is set. 403 M Mail When Printed "notification-events" = 'job- 404 completion' and "notification- 405 method" = 'mailto://Job- 406 originating-user@job-originating- 407 host' 409 N Name of source file "document-name" This is on a per 410 data file basis 412 P User identification "job-originating-user" 414 S Symbolic link data None. 416 T Title for pr None. 418 U Unlink data file None. 420 W Width of output None. 422 1 troff R font None. 424 2 troff I font None. 426 3 troff B font None. 428 4 troff S font None. 430 Mapping between LPD and IPP Protocols June 27, 1997 432 c Plot CIF file "document-format" = 'CIF' ** 434 d Print DVI file "document-format" = 'TeX DVI' ** 436 f Print formatted file "document-format" = 'Automatic' 438 In practice, this value is often 439 overloaded. It is often used with 440 any format of document data 441 including PostScript and PCL data. 443 g Plot file "document-format" = 444 'BSDPlotLibrary' ** 446 k reserved for None. 447 Kerberized clients 448 and servers This is unimplemented in LPD 449 implementations. It was a place 450 holder for future work that never 451 occurred. 453 l Print file leaving "document-format" = 'Automatic' 454 control characters 455 In practice, this is often used as 456 a rough equivalent to the `f' 457 directive. Again it may mean one 458 of many document formats. 460 n Print ditroff output "document-format" = 'ditroff' ** 461 file 463 o Print Postscript "document-format" = 'ps' 464 output file "document-format" = 'PS'(7) 466 o is recognized by LPD-to-IPP, but 467 never generated in IPP-to-LPD. 468 Rather `f' is used. 470 This was not implemented in any 471 RFC-1179 implementations until 472 very recently in WinNT. 474 p Print file with 'pr' None. 475 format 476 It therefore is equivalent to `f' 477 or `l' 479 Mapping between LPD and IPP Protocols June 27, 1997 481 r File to print with "document-format" = 'FORTRAN' ** 482 FORTRAN carriage 483 control 485 t Print troff output "document-format" = 'troff' ** 486 file 488 v Print raster file "document-format" = 'RasterFormat' 489 ** 491 z reserved for future None. 492 use with the 493 Palladium print This was reserved for the MIT 494 system Palladium print system, but was 495 never used by that system. 497 6. Bibliography 499 [1] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet 500 Printing Protocol/1.0: Model and Semantics", , July 1997. 503 [2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing 504 Protocol/1.0: Protocol specification", , 505 July 1997. 507 [3] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, August 508 1990. 510 [4] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., 511 "Printer MIB", RFC 1759, March 1995. 513 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 514 Levels", RFC 2119 , March 1997 516 [6] D. Crocker et al., ``ugmented BNF for Syntax Specifications: 517 ABNF', draft-ietf-drums-abnf-02.txt. 519 7. Author's Addresses 520 Thomas N. Hastings 521 Xerox Corporation 522 701 S. Aviation Blvd., ESAE-231 523 El Segundo, CA 90245 525 Phone: 310-333-6413 526 Fax: 310-333-5514 527 EMail: hastings@cp10.es.xerox.com 528 Mapping between LPD and IPP Protocols June 27, 1997 530 Robert Herriot 531 Sun Microsystems Inc. 532 2550 Garcia Ave., MPK-17 533 Mountain View, CA 94043 535 Phone: 415-786-8995 536 Fax: 415-786-7077 537 Email: robert.herriot@eng.sun.com 539 Norm Jacobs 540 Sun Microsystems Inc. 541 1430 Owl Ridge Rd. 542 Colorado Springs, CO 80919 544 Phone: (719) 532-9927 545 Fax: (719) 535-0956 546 Email: Norm.Jacobs@Central.sun.com 548 Jay Martin 549 Underscore Inc. 550 41-C Sagamore Park Rd. 551 Hudson, NH 03051-4915 553 Phone: (603) 889-7000 554 Fax: (603) 889-2600 555 Email: jkm@underscore.com