INTERNET-DRAFT Tom Hasting Xerox Corporation Bob Herriot Sun Microsystems, Inc. Norm Jacobs Sun Microsystems, Inc. Jay Martin Underscore, Inc. July 13, 1997 Mapping between LPD and IPP Protocols Expires Jan 13, 1998 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet-Draft specifies the mapping between (1) the commands and operands of the "Line Printer Daemon (LPD) Protocol" specified in RFC 1179 and (2) the operations and parameters of the Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. WARNING: RFC 1179 was not on standards track. While RFC 1179 was intended to record existing practice, in some areas it fell short. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementors. Hastings, Herriot, Jacobs, Martin [Page 1] Mapping between LPD and IPP Protocols June 27, 1997 TABLE OF CONTENTS 1. INTRODUCTION........................................................3 2. TERMINOLOGY.........................................................3 3. MAPPING BETWEEN LPD COMMANDS AND IPP OPERATIONS....................3 3.1 Print any waiting jobs ...........................................4 3.2 Receive a printer job ............................................4 3.3 Send queue state (short) .........................................5 3.4 Send queue state (long) ..........................................5 3.5 05 - Remove jobs .................................................6 4. MAPPING BETWEEN LPD SUB-COMMANDS AND IPP OPERATIONS.................6 4.1 01 - Abort job () ................................................6 4.2 02 - Receive control file ........................................7 4.3 03 - Receive data file ...........................................7 5. MAPPING OF LPD CONTROL FILE LINES TO IPP OPERATION INPUT PARAMETERS.7 6. BIBLIOGRAPHY.......................................................10 7. AUTHOR'S ADDRESSES.................................................10 Hastings, Herriot, Martin [Page 2] Mapping between LPD and IPP Protocols June 27, 1997 Mapping between the LPD and IPP Protocols 1. Introduction The reader of this specification is expected to be familiar with the IPP Model and Semantics specification [1], the IPP Protocol specification [2], and the Line Printer Daemon (LPD) protocol specification [3] as described in RFC 1179. RFC 1179 was written in 1990 in an attempt to document existing LPD protocol implementations. Since then, a number of undocumented extensions have been made by vendors to support functionality specific to their printing solutions. All of these extensions consist of additional control file directives. This document does not address any of these vendor extensions. Rather it addresses existing practice within the context of the features described by RFC 1179. Deviations of existing practice from RFC 1179 are so indicated. In the area of document formats, also known as page description languages (PDL), RFC 1179 defines a fixed set with no capability for extension. Consequently, some new PDL's are not supported, and some of those that are supported are sufficiently unimportant now that they have not been registered for use with the Printer MIB[4] and IPP[1] [2], though they could be registered if desired. See the Printer MIB specification [4] and/or the IPP Model specification [1] for instructions for registration of document-formats with IANA. IANA lists the registered document-formats as "printer languages". Other LPD commands are intended to work on "text" only formats and so are inappropriate for many contemporary document formats that completely specify each page. This document addresses the protocol mapping for both directions: mapping of the LPD protocol to the IPP protocol and mapping of the IPP protocol to the LPD protocol. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. The syntax of the LPD commands is given using ABNF [6]. The following tokens are used in order to make the syntax more readable: LF stands for %x0A (linefeed) Hastings, Herriot, Martin [Page 3] Mapping between LPD and IPP Protocols June 27, 1997 SP stands for %x20. (space) 3. Mapping between LPD Commands and IPP Operations This section describes the mapping between LPD on-the wire and IPP operations. Each of the following sub-sections appear as sub-sections of section 5 of RFC 1179. 3.1 Print any waiting jobs Command syntax: %x01 Printer-queue-name LF In LPD, this comment starts the daemon, if it isn't already running. Such an equivalent operation is not provided in IPP, since the IPP Printer is assumed to always be running, where as in LPD, the client makes sure that the daemon is running using this command. If an LPD-to-IPP mapper receives this LPD command, it SHALL ignore it and send no IPP operation. An IPP-to-LPD mapper SHALL send this LPD command after it has finished sending all pending `Receive a printer job' commands. 3.2 Receive a printer job Command syntax: %x02 Printer-queue-name LF An LPD-to-IPP mapper SHALL map the 'Receive a printer job' command to either: . the Print-Job operation with a single data file or . the Create-Job operation followed by a Send-Document operation for each data file. If a job consists of a single data file, the PrintJob operation is RECOMMENDED. If a job consists of more than one data file, Create Job followed by Send-Document for each data file is REQUIRED. If the IPP Printer doesn't support the Create-Job and Send-Document operations, the LPD-to- IPP mapper SHALL submit each data file as a separate Print-Job operation (thereby converting a single LPD job into multiple IPP jobs). ISSUE: Ok that I changed so that the mapper shall break a multi-document job into separate jobs, one IPP job for each LPD data file, instead of error return? Hastings, Herriot, Martin [Page 4] Mapping between LPD and IPP Protocols June 27, 1997 NOTE: if Create-Job is used, it MUST precede the Send-Document operation even if the LPD control file, which supplies attributes for Create-Job, arrives after all documents. An IPP-to-LPD mapper SHALL map the following IPP operations to this LPD command: . Print-Job . Print-uri . Create-Job followed by Send-Document or Send-URI for each document The mechanism for mapping between an LPD Printer-queue-name operand and the IPP "printer-uri" parameter is not defined in this document. ISSUE: error code conversion. See the next section for the mapping of the LPD "second level commands" to IPP input-parameters. 3.3 Send queue state (short) Command syntax: %x03 Printer-queue-name *( SP ( User-Name / job-number) ) If the LPD command contains only the Printer-queue-name operand, the LPD-to-IPP mapper SHALL use the Get-Attributes operation of the corresponding IPP Printer to get printer-state information and the Get- Jobs operation of the Printer to get information about all of the jobs. With Get-Attributes, it SHALL request the "printer-state" and "printer- state-reasons" attributes. With Get-Jobs, it SHALL request the "number- of-intervening-jobs", "job-originating-user", "job-name", "document- name" (or "document-uri"), and "job-k-octets". NOTE: RFC 1179 does not specify what attributes are returned in response to a 'Send queue state' (short) command, but leaves it up to implementation. The IPP attributes specified in this specification reflect existing practice. NOTE: This specification does not specify how the LPD-to-IPP mapper maps: (1) the LPD Printer-queue-name operand to the IPP "printer-uri" parameter or (2) the LPD job-number operand to the IPP "job-uri" parameter, since the format of these URIs is opaque in the IPP protocol and is implementation-dependent. Hastings, Herriot, Martin [Page 5] Mapping between LPD and IPP Protocols June 27, 1997 If the LPD command contains one or more User-name operands, the LPD-to- IPP mapper SHALL get all the jobs as above using the Get-Jobs operation on the Printer and then do its own filtering on the returned value of the "job-originating-user" attribute for each job. If the LPD command contains only job-number operands, the LPD-to-IPP mapper SHALL either (1) get all the jobs as above using the Get-Jobs operation on the Printer and then do its own filtering or (2) get each specified job individually using separate Get-Attributes operations (multiple jobs may be requested in a single IPP connection with multiple Get-Attribute operations, one for each job). The IPP-to-LPD mapper shall use the long version of this command. See that command. 3.4 Send queue state (long) Command syntax: %x04 printer-name *( SP ( user-name / job-number) ) Same mapping as the 'Send queue state' (short) command. The IPP client supplies a longer list of requested attributes to the Get-Jobs or Get- Attributes operations. The LPD-to-IPP mapper should specify additional attributes than the ones listed for the 'Send queue state' (short) command. NOTE: RFC 1179 does not specify what attributes are returned in response to a 'Send queue state' (short) command, but leaves it up to implementation. The IPP-to-LPD mapper shall use this command to get what attributes it can from the LPD server. 3.5 05 - Remove jobs Command syntax: %x05 Printer-queue-name SP agent *(SP (User-name / job- number)) The agent operand is the user-name of the user initiating the 'Remove jobs' command. The special user-name 'root' indicates a privileged user. The LPD-to-IPP mapper shall map this command to the Cancel-Job operation. This command with the Printer-queue-name operand and one job-number operand is the same as the IPP Cancel-Job operation when the client supplies just the job URI. Multiple jobs may be canceled in IPP in a Hastings, Herriot, Martin [Page 6] Mapping between LPD and IPP Protocols June 27, 1997 single connection with multiple Cancel-Job operations. In IPP only a privileged operator may cancel jobs belonging to another user. NOTE: This specification does not specify how the LPD-to-IPP mapper maps: (1) the LPD Printer-queue-name to the IPP "printer-uri" or (2) the LPD job-number to the IPP "job-uri", since the format of these URIs is opaque in the IPP protocol and is implementation-dependent. There is no IPP equivalent for the LPD 'Remove jobs' command with just the Printer-queue-name operand supplied, since IPP provides no way to cancel the current job. There is no IPP equivalent for the LPD 'Remove jobs' command with a User-name operand supplied, since IPP provides no way to cancel a job specified by user name. The LPD-to-IPP mapper shall map a Cancel-Job operation to this command. There are some major issues about setting the agent. 4. Mapping between LPD Sub-Commands and IPP Operations This section describes the mapping between LPD sub-commands and IPP operations. Each of the following sub-sections appear as sub-sections of section 6 of RFC 1179. The operands of the sub-commands appear in parens in the sub-headings 4.1 01 - Abort job () Sub-command syntax: %x01 This sub-command is intended to abort any job transfer in process. If an IPP Create-Job operation and/or a Send-Document operation were performed on behalf of the receive job command that is being aborted, an IPP Cancel-Job operation should be issued for the job URI that was returned by the Printer on which the Create-Job operation was performed. Also, any temporary files created while processing the 'Receive job request' should be cleaned up, and the connection to the client should be closed. Finally, this sub-command is implied if at any time the connection between the LPD client and server is terminated before an entire print job has been transferred via an LPD 'Receive job request'. ISSUE: is IPP defined at this point to abort a job whose connection is closed before the job has been fully received. If so, that is an alternate and simpler way to abort the job. Hastings, Herriot, Martin [Page 7] Mapping between LPD and IPP Protocols June 27, 1997 4.2 02 - Receive control file Sub-command syntax: %x02 Number-of-bytes-in-control-file, Name-of- control-file This sub-command is roughly equivalent to the IPP Create-Job operation. Once the control file has been has been received, it's contents should be translated, and an appropriate IPP Create-Job operation performed. However, some information, such as Document-Name go in the Send-Document operation. 4.3 03 - Receive data file Sub-command syntax: %x03 Number-of-bytes-in-data-file Name-of-data-file This sub-command is roughly equivalent to the IPP Send-Document operation. If the control file has been previously received, and it's corresponding IPP Create-Job operation performed, an IPP Send-Document operation can be performed using the job URI returned by the IPP Create- Job operation. When performing the Send-Document operation, the size of the document data MUST be specified. Unfortunately RFC-1179 alludes to a method for passing an arbitrary length data file. This is described as being done by using an octet-count of zero, however the description isn't complete, and in practice, no implementations allow sending or receiving arbitrary length data files. 5. Mapping of LPD control file lines to IPP Operation Input Parameters This section describes the mapping from LPD control file lines to IPP operation input parameters for the Print-Job, Create-Job, and Send- Document operations. Each of the following sub-sections appear as sub- sections of section 7 of RFC 1179. ISSUE: somewhere, we need to map the LPD query format to IPP attributes. In LPD text operands have a maximum length of 31 or 99 while IPP input parameters have a maximum of 255 characters. Therefore, no data is lost when mapping from LPD to IPP. However, when mapping from IPP to LPD, there may be some data loss if the IPP parameters exceed the maximum length of the LPD equivalent operands. In the following table, IPP input parameter names are indicated in double quotes (") and input parameter values are indicated in single quotes ('). Values of the IPP "document-format" attribute that could be registered, but are not currently, are indicated with "**". Hastings, Herriot, Martin [Page 8] Mapping between LPD and IPP Protocols June 27, 1997 Where there is a one-to-one mapping, both directions are specified. Where IPP has none, the LPD-to-IPP the attribute is ignored, and in the IPP-to-LPD the LPD feature is left unspecified. LPD command Equivalent IPP input parameter(s) C Class for banner None. page H Originating Host "job-originating-host" I Indent Printing None. J Job name for banner "job-name" page L Print banner page "job-sheets" = any but 'none' Absence of an `L' directive indicates that ``job-sheets=none'' is set. M Mail When Printed "notification-events" = 'job- completion' and "notification- method" = 'mailto://Job- originating-user@job-originating- host' N Name of source file "document-name" This is on a per data file basis P User identification "job-originating-user" S Symbolic link data None. T Title for pr None. U Unlink data file None. W Width of output None. 1 troff R font None. 2 troff I font None. 3 troff B font None. 4 troff S font None. Hastings, Herriot, Martin [Page 9] Mapping between LPD and IPP Protocols June 27, 1997 c Plot CIF file "document-format" = 'CIF' ** d Print DVI file "document-format" = 'TeX DVI' ** f Print formatted file "document-format" = 'Automatic' In practice, this value is often overloaded. It is often used with any format of document data including PostScript and PCL data. g Plot file "document-format" = 'BSDPlotLibrary' ** k reserved for None. Kerberized clients and servers This is unimplemented in LPD implementations. It was a place holder for future work that never occurred. l Print file leaving "document-format" = 'Automatic' control characters In practice, this is often used as a rough equivalent to the `f' directive. Again it may mean one of many document formats. n Print ditroff output "document-format" = 'ditroff' ** file o Print Postscript "document-format" = 'ps' output file "document-format" = 'PS'(7) o is recognized by LPD-to-IPP, but never generated in IPP-to-LPD. Rather `f' is used. This was not implemented in any RFC-1179 implementations until very recently in WinNT. p Print file with 'pr' None. format It therefore is equivalent to `f' or `l' Hastings, Herriot, Martin [Page 10] Mapping between LPD and IPP Protocols June 27, 1997 r File to print with "document-format" = 'FORTRAN' ** FORTRAN carriage control t Print troff output "document-format" = 'troff' ** file v Print raster file "document-format" = 'RasterFormat' ** z reserved for future None. use with the Palladium print This was reserved for the MIT system Palladium print system, but was never used by that system. 6. Bibliography [1] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", , July 1997. [2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing Protocol/1.0: Protocol specification", , July 1997. [3] L. McLaughlin, "Line Printer Daemon Protocol", RFC 1179, August 1990. [4] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119 , March 1997 [6] D. Crocker et al., ``ugmented BNF for Syntax Specifications: ABNF', draft-ietf-drums-abnf-02.txt. 7. Author's Addresses Thomas N. Hastings Xerox Corporation 701 S. Aviation Blvd., ESAE-231 El Segundo, CA 90245 Phone: 310-333-6413 Fax: 310-333-5514 EMail: hastings@cp10.es.xerox.com Hastings, Herriot, Martin [Page 11] Mapping between LPD and IPP Protocols June 27, 1997 Robert Herriot Sun Microsystems Inc. 2550 Garcia Ave., MPK-17 Mountain View, CA 94043 Phone: 415-786-8995 Fax: 415-786-7077 Email: robert.herriot@eng.sun.com Norm Jacobs Sun Microsystems Inc. 1430 Owl Ridge Rd. Colorado Springs, CO 80919 Phone: (719) 532-9927 Fax: (719) 535-0956 Email: Norm.Jacobs@Central.sun.com Jay Martin Underscore Inc. 41-C Sagamore Park Rd. Hudson, NH 03051-4915 Phone: (603) 889-7000 Fax: (603) 889-2600 Email: jkm@underscore.com Hastings, Herriot, Martin [Page 12]