[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 rfc2569                                     
 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

                  <draft-ietf-ipp-lpd-ipp-map-00.txt>

                          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", <draft-ietf-ipp-model-
02.txt>, July 1997.

[2] R. Herriot, S. Butler, P. Moore, R. Turner, "Internet Printing
Protocol/1.0: Protocol specification", <draft-ietf-ipp-protocol-00.txt>,
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]