INTERNET-DRAFT                                              Tom Hasting
                                                       Xerox Corporation
                                                             Bob

                                                 Robert Herriot (editor)
                                                  Sun Microsystems, Inc.
                                                            Tom Hastings
                                                       Xerox Corporation
                                                             Norm Jacobs
                                                  Sun Microsystems, Inc.
                                                              Jay Martin
                                                        Underscore, Inc.
                                                           July 13, 30, 1997

                 Mapping between LPD and IPP Protocols

                  <draft-ietf-ipp-lpd-ipp-map-00.txt>
                  <draft-ietf-ipp-lpd-ipp-map-01.txt>
                          Expires Jan 13, 30, 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. short in some areas.
     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.

           Mapping between LPD and IPP Protocols          June 27, 1997 implementers.

Jacobs, Martin          Expires January 30, 1998
                           TABLE OF CONTENTS

1. INTRODUCTION........................................................3 Introduction........................................................3
2. TERMINOLOGY.........................................................3 Terminology.........................................................3
3. MAPPING BETWEEN Mapping from LPD COMMANDS AND Commands to IPP OPERATIONS....................3 Operations.........................4
 3.1 Print any waiting jobs ...........................................4
 3.2 Receive a printer job ............................................4
   3.2.1 Abort job ....................................................5
   3.2.2 Receive control file .........................................6
   3.2.3 Receive data file ............................................6
 3.3 Send queue state (short) .........................................5 .........................................6
 3.4 Send queue state (long) ..........................................5 ..........................................8
 3.5 05 - Remove jobs .................................................6 ......................................................9
4. MAPPING BETWEEN Mapping of LPD SUB-COMMANDS AND Control File Lines to IPP OPERATIONS.................6 Parameters................10
 4.1 01 - Abort job () ................................................6 Required Job Functions ..........................................10
 4.2 02 - Receive control file ........................................7 Optional Job Functions ..........................................11
 4.3 03 - Receive data file ...........................................7 Required Document Functions .....................................12
 4.4 Recommended Document Functions ..................................13
5. MAPPING OF Mapping from IPP operations to LPD CONTROL FILE LINES TO IPP OPERATION INPUT PARAMETERS.7 commands........................13
 5.1 Get-Operations ..................................................13
 5.2 Print-Job .......................................................13
 5.3 Print-URI .......................................................14
 5.4 Validate-Job ....................................................15
 5.5 Create-Job ......................................................15
 5.6 Send-Document ...................................................15
 5.7 Send-URI ........................................................15
 5.8 Cancel-Job ......................................................15
 5.9 Get-Attributes ..................................................16
 5.10 Get-Jobs .......................................................17
6. BIBLIOGRAPHY.......................................................10

7. AUTHOR'S ADDRESSES.................................................10 Mapping between LPD and of IPP Protocols          June 27, 1997 Parameters to LPD Control File Lines................17
 6.1 Required Job Functions ..........................................17
 6.2 Optional Job Functions ..........................................18
 6.3 Required Document Functions .....................................18
7. References.........................................................19
8. Author's Addresses.................................................19
9. Appendix A: ABNF Syntax for response of Send-queue-state (short)...20
10. Appendix B: ABNF Syntax for response of Send-queue-state (long)...20
11. Appendix C: Unsupported LPD functions.............................21

Jacobs, Martin          Expires January 30, 1998
               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. commands.  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.

Other LPD control file commands in RFC 1179 are obsolete. They are
intended to work on "text" only formats and are inappropriate for many
contemporary document formats that completely specify each page. This
document does not address the support of these obsolete features.

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. The former is called the "LPD-to-IPP
mapper" and the latter is called the "IPP-to-LPD mapper".

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].

RFC 1179 uses the word "command" in two contexts: for over-the-wire
operations and for command file functions. This document SHALL use the
word "command" for the former and the phrase "functions" for the latter.
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)
           Mapping between LPD and IPP Protocols          June 27, 1997
Jacobs, Martin          Expires January 30, 1998
    SP stands for %x20.  (space)
    DIGIT stands for %x30-39 ("0" to "9")

3. Mapping between from LPD Commands and to IPP Operations

This section describes the mapping between from LPD on-the wire and commands  to IPP operations.
Each of the following sub-sections appear as sub-sections of section 5
of RFC 1179.

The following table summarizes the IPP operation that the mapper uses
when it receives an LPD command. Each section below gives more detail.

LPD command                IPP operation

print-any-waiting-jobs     ignore
receive-a-printer-job      Print-Job or Create-Job/Send-Document
send queue state           Get-Attributes (printer) and Get-Jobs
(short or long)
remove-jobs                Cancel-Job

3.1 Print any waiting jobs

Command syntax:

  print-waiting-jobs = %x01 Printer-queue-name printer-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

This command causes the LPD daemon is running using this command. check its queue and print any waiting
jobs. An IPP printer handles waiting jobs without such a nudge.

If an LPD-to-IPP the  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:

  receive-job = %x02 Printer-queue-name printer-name LF

An LPD-to-IPP

The control file and data files mentioned in the following paragraphs
are received via LPD sub-commands that follow this command. Their
mapping to IPP commands and attributes is described later in this
section.

The mapper SHALL map maps the 'Receive a printer job' command to either:

  .  the Print-Job operation with which includes a single data file or
  .  the  Create-Job  operation   followed  by a  one   Send-Document
     operation for each data file.

If the IPP printer supports both Create-Job and Send-Document, and if a
job consists of of:

Jacobs, Martin          Expires January 30, 1998
  .  a single  data  file,  the  mapper  SHOULD  use  the  PrintJob operation is
RECOMMENDED.

If a job consists of
     operation,  but  MAY  use  the  Create-Job  and  Send-Document
     operations.
  .  more than  one data  file, the  mapper  SHALL use  Create  Job
     followed by one Send-Document for each received LPD data file is REQUIRED. file.

If the IPP Printer
doesn't printer does not support the both Create-Job and Send-Document operations, Send-Document,
and if a job consists of:

  .  a  single  data  file,  the  mapper  SHALL  use  the  PrintJob
     operation.
  .  more than one data file, the LPD-to-
IPP mapper SHALL submit each received
     LPD 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

If the mapper shall break a multi-document
job into separate jobs, one IPP job for each LPD data file, instead of
error return?
           Mapping between LPD and IPP Protocols          June 27, 1997

NOTE: if uses Create-Job is used, and Send-Document, it MUST precede send the Send-Document
Create-Job operation
even if before it sends any Send-Document operations
whether the LPD control file, which supplies attributes for Create-Job,
arrives before or after all documents.

An IPP-to-LPD LPD data files.

NOTE:  This specification does not specify how the mapper SHALL map maps: 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
Printer-name operand and to the IPP "printer-uri" parameter is not defined in this document.

ISSUE: error code conversion.

See the next section for parameter.

The following 3 sub-sections gives further details about 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
from  LPD command contains only receive-a-printer-job sub-commands.  Each of the Printer-queue-name operand, following
sub-sections appear as sub-sections of section 6 of RFC 1179.

ISSUE: the
LPD-to-IPP mapper SHALL use needs to maintain information such as the Get-Attributes operation mapping of the
each job-number  to its corresponding job-URI.  It would be nice for IPP Printer
to get printer-state information and the Get-
Jobs operation of support an "scratch-pad" attribute for the Printer mapper to get encode such
information. Then it  wouldn't have to maintain this information about all
separately.

3.2.1 Abort job

Sub-command syntax:

  abort-job = %x1 LF

This sub-command of receive-a-printer-job is intended to abort any job
transfer in process.

If the jobs.
With Get-Attributes, mapper receives this sub-command, it SHALL request cancel the "printer-state" and "printer-
state-reasons" attributes.  With Get-Jobs, job that it SHALL request
is in 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 process of transmitting.

If the mapper is in
response to the process of sending a 'Send queue state' (short) command, but leaves Print-Job or Create-Job
operation, 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) terminates the LPD Printer-queue-name operand to job either by closing the IPP "printer-uri"
parameter connection, or (2)
performing the LPD job-number operand to Cancel-Job operation with the IPP "job-uri"
parameter, since job-uri that it received
from the format of these URIs Print-Job or Create-Job operation.

NOTE: This sub-command is opaque in implied if at any time the IPP protocol
and is implementation-dependent.

           Mapping connection 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 client and then do its own filtering on server is terminated before an entire print job has
been transferred via an LPD Receive-a-printer-job request.
Jacobs, Martin          Expires January 30, 1998

3.2.2 Receive control file

Sub-command syntax:

  receive-control-file = %x2 number-of-bytes SP name-of-control-file LF
  number-of-bytes = 1*DIGIT
  name-of-control-file = "cfA" job-number client-host-name
                          ; e.g. "cfA123woden"
  job-number = 3DIGIT
  client-host-name = <a host name>

This sub-command is roughly equivalent to the returned value IPP Create-Job operation.

The mapper SHALL use the contents of the "job-originating-user" received LPD control file to
create IPP parameter and attribute values to transmit with the Print-Job
or Create-Job operation.

3.2.3 Receive data file

Sub-command syntax:  %x3 number-of-bytes-in-data-file Name-of-data-file

  receive-data-file = %x03 number-of-bytes SP name-of-data-file LF
  number-of-bytes = 1*DIGIT
  name-of-data-file = "df" letter job-number client-host-name
              ; e.g. "dfA123woden for each job.

If the LPD command contains only first file
  letter = %x41-5A /  %x61-7A    ;  "A" to "Z", "a" to "z"
                                 ;  first file is "A",
                                 ; second "B", and  52nd file is "z"
  job-number operands, = 3DIGIT
  client-host-name = <a host name>

This sub-command is roughly equivalent to the LPD-to-IPP IPP Send-Document
operation.

The mapper SHALL either (1) get all use the jobs contents of the received LPD data file as above using the Get-Jobs
operation on
data to transmit with the Printer and then do its own filtering IPP Print-Job or (2) get each
specified job individually using separate Get-Attributes operations
(multiple jobs may be requested in Send-Document operation.

Although  RFC-1179 alludes to a single IPP connection with multiple
Get-Attribute operations, one method for each job).

The IPP-to-LPD mapper shall use the long version passing an unspecified
length data file by using an octet-count of zero, no implementations
support this command. See feature.. The mapper SHALL reject a job that command.

3.4 has a value of
0 in the number-of-bytes field.

3.3 Send queue state (long) (short)

Command syntax:  %x04

  send-queue-short  = %x03 printer-name *( SP ( user-name *(SP(user-name / job-number) )

Same mapping as the 'Send queue state' (short) command. job-number)) LF

The IPP client
supplies a longer list of requested attributes mapper's response to this command includes information about 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:
printer and its jobs. 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 specifies neither 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 information nor the user-name
format of its response. This document requires 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 follow
existing practice as specified in this document.
Jacobs, Martin          Expires January 30, 1998

The mapper SHALL produce a response in the Cancel-Job
operation.

This command with the Printer-queue-name operand following format which
consists of a printer-status line optionally followed by a heading line,
and one job-number
operand a list of jobs. This format is defined by examples below. Appendix A
contains the same as the IPP Cancel-Job operation when the client
supplies just ABNF syntax.

For an printer with no jobs, the job URI.  Multiple jobs may be canceled in IPP response starts in a
           Mapping between LPD column 1 and IPP Protocols          June 27, 1997

single connection with multiple Cancel-Job operations.  In IPP only is:

no entries

For a
privileged operator may cancel jobs belonging to another user.

NOTE: This specification does not specify how printer with jobs, an example of the LPD-to-IPP response is:

killtree is ready and printing
Rank   Owner      Job          Files             Total Size
active fred       123          stuff             1204 bytes
1st    smith      124          resume, foo       34576 bytes
2nd    fred       125          more              99 bytes
3rd    mary       126          mydoc             378 bytes
4th    jones      127          statistics.ps     4567 bytes
5th    fred       128          data.txt          9 bytes

The column numbers of above headings and job entries are:

|      |          |            |                 |
01     08         19           35                63

The mapper
maps: (1) SHALL produce each field above from the following IPP
attribute:

   LPD Printer-queue-name to the field IPP "printer-uri" attribute           special conversion details

   printer-  printer-state and       For a printer-state of idle or (2)
   status    printer-state-reasons   processing, the
LPD job-number mapper SHALL use
                                     the formats above.  For stopped,
                                     the mapper SHALL use printer-
                                     state-reasons to produce an
                                     unspecified format for the IPP "job-uri", since error.
   rank      number-of-              the mapper SHALL the format above
             intervening-jobs
   owner     job-originating-user    unspecified conversion; job-
                                     originating-user may be the
                                     mapper's user-name
   job       job-uri                 unspecified conversion
   files     document-name           the mapper shall create a comma
                                     separated list of these URIs is
opaque in the IPP protocol document-
                                     names and is implementation-dependent.

There is no IPP equivalent for then truncate this list
                                     to the LPD 'Remove jobs' command with just first 24 characters
   total-    job-k-octets            the Printer-queue-name operand supplied, since IPP provides no way to
cancel mapper shall multiple the current job.

There is no IPP equivalent for
   size                              value of job-k-octets by 1024.

A mapper SHOULD use the LPD 'Remove jobs' command with job attribute number-of-intervening-jobs rather
than the job's position in a
User-name operand supplied, since IPP provides no way list of jobs to cancel determine `rank' because a
Printer may omit jobs that it wants to keep secret. If a printer doesn't

Jacobs, Martin          Expires January 30, 1998

support the job
specified by user name.

The LPD-to-IPP mapper shall map attribute number-of-intervening-jobs, a Cancel-Job operation to this command.

There are some major issues about setting mapper MAY use
the agent.

4. Mapping between LPD Sub-Commands and IPP Operations

This section describes job's position.

ISSUE: is job-k-octets the mapping between LPD sub-commands and IPP
operations.  Each sum of the following sub-sections appear as sub-sections bytes of section 6 each document times the
number of RFC 1179. copies? If so, "total-size" is 1024 times job-k-octets.  The operands of
model document needs clarification.

In order to obtain the sub-commands appear in
parens in information specified above, The LPD-to-IPP
mapper SHALL use 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 Get-Attributes operation were
performed on behalf of the receive job command that is being aborted, an
IPP Cancel-Job printer to get
printer-status and SHOULD use the Get-Jobs operation should be issued for to get information
about all of the job URI that was
returned by jobs. If the Printer on which LPD command contains job-numbers or user-
names, the Create-Job operation was performed.
Also, any temporary files created while processing mapper handles the 'Receive job
request' should be cleaned up, and filtering of the connection response because Get-Jobs
has no way to limit jobs to those of a particular user. If the client should
be closed.  Finally, this sub-command is implied if at any time LPD
command contains job-numbers but no user-names, the
connection between mapper MAY use Get-
Attributes on each converted job-number rather than Get-Jobs.

NOTE:  This specification does not define how 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 mapper maps the job.

           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
Printer-name operand 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 "printer-uri" parameter.

3.4 Send queue state (long)

Command syntax:  %x03 Number-of-bytes-in-data-file Name-of-data-file

This sub-command is roughly equivalent

  send-queue-long = %x04 printer-name *(SP(user-name / job-number)) LF

The mapper's response to this command includes information about the IPP Send-Document
operation.  If the control file has been previously received,
printer 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 its jobs. RFC 1179 specifies neither the Send-Document operation, information nor the size
format of the its response. This document
data MUST be specified.  Unfortunately RFC-1179 alludes requires the mapper to follow
existing practice as specified in this document.

The mapper SHALL produce a method response in the following format which
consists of a printer-status line optionally followed a list of jobs,
where each job consists of a blank line, a description line, and one
line for
passing an arbitrary length data each file. The description line contains the user-name, rank,
job-number and host. This format is described as being done defined by using examples below. Appendix
B contain the ABNF syntax.

For an octet-count printer with no jobs the response is:

no entries

For a printer with jobs, an example of zero, however the description isn't complete, response is:

killtree is ready and in practice, no implementations allow sending or receiving arbitrary
length data files.

5. Mapping printing

fred: active                        [job 123 tiger]
        2 copies of LPD control file lines to IPP Operation Input Parameters

This section describes stuff           602 bytes

smith: 1st                          [job 124 snail]
        2 copies of resume          7088 bytes
        2 copies of foo             10200 bytes

fred: 2nd                           [job 125 tiger]
Jacobs, Martin          Expires January 30, 1998
        more                        99 bytes

The column numbers of above headings and job entries are:

|       |                           |
01      09                          41

Although the mapping format of the long form is different from LPD control file lines to IPP
operation input parameters the format of the
short form, their fields are identical except for the Print-Job, Create-Job, copies and Send-
Document operations.  Each host
fields which are only in the long form.  For fields other than the host
and copies fields, see the preceding section. For the host field see the
table below.

   LPD field IPP attribute         special conversion details

   host      job-originating-host  unspecified conversion; job-
                                   originating-host may be the
                                   mapper's host
   copies    copies                the mapper shall assume the
                                   value of copies precedes the following sub-sections appear as sub-
sections
                                   string "copies of section 7 "; otherwise,
                                   the value of RFC 1179.

ISSUE: somewhere, we need to map copies is 1.

NOTE:  This specification does not define how the mapper maps the LPD query format
Printer-name operand to the IPP attributes.

In LPD text operands have a maximum length printer-uri parameter.

3.5 Remove jobs

Command syntax:

  remove-jobs = %x05 printer-name SP agent
                      *(SP(user-name / job-number)) LF

The agent operand is the user-name of 31 or 99 while IPP input
parameters have the user initiating the remove-
jobs command. The special user-name 'root' indicates a maximum of 255 characters.  Therefore, no data is lost
when mapping privileged user
who can remove jobs whose user-name differs from LPD to IPP.  However, the agent..

The mapper SHALL issue one Cancel-Job operation for each job referenced
by the remove-jobs command. Each job-number in the remove-jobs command
references a single job. Each user-name in the remove-jobs command
implicitly references all jobs owned by the specified user. The active
job is implicitly referenced when mapping from IPP the remove-jobs command contains
neither job-numbers nor user-names. The mapper MAY use Get-Job to LPD,
there may be some data loss if
determine the IPP parameters exceed job-uri of implicitly referenced jobs.

The mapper SHALL not use the maximum
length 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 LPD equivalent operands. printer to issue a notification that
misleads a user into thinking that some other person canceled the job.

If the agent of a remove-jobs command for a job J is the same as the
user name specified with the `P' function in the control file for job J,
Jacobs, Martin          Expires January 30, 1998

then the mapper SHALL ensure that the caller of the Cancel-Job command
for job J is the same as  job-originating-user for job J.

Note: This requirement means that a mapper must be consistent in who the
receiver perceives as the caller of IPP operations. The mapper either
acts as itself or acts on behalf of another user. The latter is
preferable if it is possible. This consistency is necessary between
Print-Job/Create-Job and Cancel-Job in order for Cancel-Job to work, but
it is also desirable for other operations. For example, Get-Jobs may
give more information about job submitted by the caller of this
operation.

NOTE: This specification does not define  how the mapper maps: (1) the
LPD printer-name to the IPP "printer-uri" or (2) the LPD job-number to
the IPP "job-uri".

NOTE: This specification does not specify how the mapper maps the LPD
user-name to the IPP job-originating-user because the mapper may use its
own user-name with jobs.

4. Mapping of LPD Control File Lines to IPP Parameters

This section describes the mapping from LPD control file lines (called
`functions') to IPP operation input parameters. The mapper receives the
control file lines via the LPD receive-control-file sub-command..  Each
of the LPD functions  appear as sub-sections of section 7 of RFC 1179.

In LPD control file lines, the following table, 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.

The mapper converts each supported LPD function to its corresponding IPP
parameter names as defined by tables in the subsections that follow. These
subsections group functions according to whether they are:

  .  required with a job,
  .  optional with a job
  .  required with each document.

In the tables below, each LPD value is given a name, such as `h'. If an
IPP value uses the LPD value, then the IPP value column contains the LPD
name, such as `h' to denote this.  Otherwise, the IPP value column
specifies the literal value.

4.1 Required Job Functions

The following LPD functions MUST be in a received LPD job. The mapper
SHALL receive each of the following LPD functions and SHALL include the
information as a parameter with each IPP job. The functions SHOULD be in
the order `H', `P' and they SHOULD be the first two functions in the
control file, but they MAY be anywhere in the control file and in any
order.
Jacobs, Martin          Expires January 30, 1998

LPD function                      IPP
name value   description          name          value

H    h       Originating Host                   h (in security layer)
P    u       User identification                u (in security layer)
             none                 best-effort   `true'

A mapper MAY sends its own host rather than the client's host, and a
mapper MAY send its own user-name as user identification rather than the
client user. But in any case, the values sent SHALL be compatible with
the Cancel-Job operation. The IPP operation MAY have no way to specify
an originating host-name.

ISSUE: what do we do about job-orginating-host?

The mapper SHALL include best-effort=true so that it doesn't have to
determine which attributes a printer supports.

4.2 Optional Job Functions

The following LPD functions MAY be in a received job. These function
SHOULD follow the required job functions and precede the document
functions, but they MAY be anywhere in the control file.

If the mapper receives such an LPD function, the mapper SHALL include
the corresponding IPP attribute with the value converted as specified in
the table below.  If the mapper does not receive such an LPD attribute,
the mapper SHALL NOT include the corresponding IPP attribute, except the
`L' LPD function whose absence has a special meaning as noted in the
table.

LPD function                    IPP
name value   description        name           value

J    j       Job name for       job-name       j
             banner page
L    l       Print banner page  job-sheets     `standard' if `L' is
                                               present
                                               `none' if `L' is present
M    m       Mail When Printed  notification-  `job-completion'
                                events         'mailto://'m`@'h
                                notification-
                                method
Note: `m' is the user name and not an email address. The mapper can
fabricate an email address with the source host.  This email address
mail fail when the `h' is some intermediary host that doesn't know about
user `m'. But there is no better solution.

Jacobs, Martin          Expires January 30, 1998

4.3 Required Document Functions

The mapper SHALL receive one set of the required document functions with
each copy of a document, and SHALL include the converted information as
parameters with each IPP document

If the control file contains required and recommended document
functions, the required functions SHOULD precede the recommended ones
and if the job contains multiple documents, all the functions for each
document are grouped together as shown in the example of section 6.3
"Required Document Functions". However, the document functions MAY be in
any order.

LPD function                    IPP
name  valu  description         name              value
      e

f     fff   Print formatted     document-format   37 (langAutomatic)
            file
l     fff   Print file leaving  document-format   37 (langAutomatic)
            control characters
o     fff   Print Postscript    document-format   6  (langPS).
            output file
                                copies            see note
Note: In practice, the `f' LPD function is often overloaded. It is often
used with any format of document data including PostScript and PCL data.

Note: In practice, the `l' LPD function is often used as a rough
equivalent to the `f' function.

Note: When RFC 1179 was written, no implementation supported the `o'
function; instead `f' was used for PostScript. Windows NT now sends `o'
function for a PostScript file.

Note: the value `fff' of the `f', `l' and `o' functions is the name of
the data file as transferred, e.g. "dfA123woden".

If the mapper receives any other lower case letter, the mapper SHALL
reject the job because the document contains a format that the mapper
does not support.

The mapper determines the number of copies by counting the number of
occurrences of each `fff' file with one of the lower-case functions
above. For example, if `f dfA123woden' occurs 4 times, then copies has a
value of 4. Although the LPD protocol allows the value of copies to be
different for each document, the commands and the receiving print
systems don't support this.

ISSUE: should we register DVI, ditroff and troff. At least DVI and one
of the troff is  still in use.

Jacobs, Martin          Expires January 30, 1998

4.4 Recommended Document Functions

The mapper SHOULD receive one set of the recommended document functions
with each document, and SHOULD include the converted information as
parameters with each IPP document. The functions SHOULD be received in
the order `U' and `N', but they MAY arrive in any order.

LPD function                        IPP
name  value   description           name              value

U     fff                           ignored
N     n       Name of source file   document-name     n

Note: the value `fff' of the `U' function is the name of the data file
as transferred, e.g. "dfA123woden".

5. Mapping from IPP operations to LPD commands

If the IPP-to-LPD mapper receives an IPP operation, the following table
summarizes the LPD command that it uses. Each section below gives the
detail. Each of the following sub-sections appear as sub-sections of
section 3 in the document "Internet Printing Protocol/1.0: Model and
Semantics" [1].

IPP operation                     LPD command

Get-Operations                    implemented by the mapper
Print-Job or Print-URI or         receive-a-printer-job
Create-Job/Send-Document/Send-URI and then print-any-waiting-jobs
Validate-Job                      implemented by the mapper
Cancel-Job                        remove-jobs
Get-Attributes (printer or job)   send queue state (short or long)
or Get-Jobs

5.1 Get-Operations

The mapper SHALL return a list of the operations that it supports. It
SHALL support at least those operations that are mandatory according to
the IPP model document [1].

5.2 Print-Job

The mapper SHALL send the following commands in the order listed below:

  .  receive-a-printer-job command
  .  both receive-control-file sub-command and receive-data-file
     sub-command
     (unspecified order, see Note below)
  .  print-any-waiting-jobs command,
     except that if the mapper is sending a sequence of receive-a-
Jacobs, Martin          Expires January 30, 1998
     printer-job commands, it MAY omit sending print-any-waiting-
     jobs after any receive-a printer-job command that is neither
     the first nor last command in this sequence

Note: it is recommended that the order of the receive-control-file sub-
command and the receive-data-file sub-command be configurable because
either order fails for some print systems. Some print systems assume
that the control file follows all data files and start printing
immediately on receipt of the control file. When such a print system
tries to print a data file that has not arrived, it produces an error.
Other print systems assume that the control file arrives before the data
files and start printing when the first data file arrives. Such a system
ignores the control information, such as banner page or copies.

NOTE: This specification does not define the mapping between the IPP
printer-uri and the LPD printer-name.

The mapper SHALL send the IPP parameters and attributes received from
the operation to the LPD printer by using the LPD receive-control-file
sub-command. The mapper SHALL create the job-number for use in the
control file name, but the receiving printer MAY, in some circumstances,
assign a different job-number to the job. The mapper SHALL create the
job-uri returned in the Print-Job response.

NOTE: This specification does not specify how the mapper determines the
job-number or the job-uri of a job that it creates nor does it specify
the relation ship between the job-uri and the job-number, both of which
the mapper creates.

The mapper SHALL send data received in the IPP operation to the LPD
printer by using the LPD receive-data-file sub-command. The mapper SHALL
specify the exact number of bytes being transmitted in the number-of-
bytes field of the receive-data-file sub-command. It SHALL NOT use a
value of 0 in this field.

If the mapper, while it is transmitting a receive-a-printer-job command
or sub-command, either detects that its IPP connection has closed or
receives a Cancel-Job operation,  the mapper SHALL terminate the LPD job
either with the abort sub-command or the remove-jobs command.

ISSUE: error code conversion.

5.3 Print-URI

The mapper SHALL handle this operation in the same way as a Print-Job
operation except that it SHALL obtain data referenced by the "document-
uri" parameter and SHALL then treat that data as if it had been received
via a Print-Job operation.

Jacobs, Martin          Expires January 30, 1998

5.4 Validate-Job

The mapper SHALL perform this operation directly. Because LPD supports
very few attributes, this operation doesn't have much to check.

5.5 Create-Job

The mapper SHALL handle this operation like Print-Job, except

  .  the mapper SHALL send the control  file after it has  received
     the last  Send-Document  or  Send-URI  operation  because  the
     control file  contains  all the  document-name  and  document-
     format values  specified  in the  Send-Document  and  Send-URI
     operations.
  .  the mapper SHALL perform one receive-data-file sub-command for
     each Send-Document or Send-URI  operation received and in  the
     same order received.
  .  the mapper SHALL send the control file either before all data
     files or after all data files.
     (See the note in the section on Print-Job about the dilemma of
     sending the control file either before or after the data
     files.

5.6 Send-Document

The mapper performs a receive-data-file sub-command on the received
data. See the preceding section 5.5 "Create-Job" for the details.

5.7 Send-URI

The mapper SHALL obtain the data referenced by the "document-uri"
parameter, and SHALL then treat that data as if it had been received via
a Send-Document operation. See the preceding section 5.6 "Send-Document"
for the details.

5.8 Cancel-Job

The mapper SHALL perform a remove-jobs command with the following
parameters:

  .  the printer is the one containing the job specified by the IPP
     job-uri,
  .  the agent is the authenticated user-name of the IPP client,
  .  the job-number is  the one  corresponding to  the IPP  job-uri
     parameter.

NOTE: This specification does not specify how the mapper maps the IPP
"job-uri"  to the LPD printer-name or LPD job-number.

Jacobs, Martin          Expires January 30, 1998

ISSUE: the model needs to offer a solution for mapping jobs to printers
either with a new job attribute "printer-uri" or with all operation
targets being a printer-uri.

5.9 Get-Attributes

LPD severely limits the set of attributes that the mapper is able to
return in its response for this operation.

When the mapper receives a Get-Attributes operation for a printer
object, it SHALL support, at most, the following printer attributes:

  .  printer-state
  .  printer-state-reasons

When the mapper receives a Get-Attributes operation for a job object, it
SHALL support, at most, the following job attributes:

  .  number-of-intervening-jobs
  .  job-originating-user
  .  job-uri
  .  job-originating-host
  .  document-name
  .  job-k-octets
  .  copies

The mapper uses either the long or short form of the "send queue state"
command. If it receives a request for the "job-originating-host" or
"copies" and supports those attribute it SHALL use the long form;
otherwise, it SHALL use the short form.

Note: the value of job-k-octets is the value in the short form, but it
can be computed from the copies and file size fields in the long form.

The mapper SHALL assume that the LPD response that it receives has the
format and information specified in section 3.3 "Send queue state
(short)"  and section 3.4 "Send queue state (long)". The mapper SHALL
determine the value of each requested attribute by using the inverse of
the mapping specified in the two aforementioned sections.

Note: when the mapper receives the Get-Attributes operation for a
printer, it can determine the response from the printer-status line
without examining the rest of the LPD response. When the mapper receives
the Get-Attributes operation for a job and uses the LPD short form, it
can determine the response from the single line that pertains to the job
specified by the Get-Attributes operation.

NOTE: For Get-Attributes of a job, this specification does not specify
how the mapper maps the IPP "job-uri"  to the LPD printer-name or LPD
job-number.

Jacobs, Martin          Expires January 30, 1998

5.10 Get-Jobs

The mapper SHALL perform this operation in the same way as Get-
Attributes of a printer except that the mapper converts the job-lines,
and the IPP response contains one job object for each job in the LPD
response..

6. Mapping of IPP Parameters to LPD Control File Lines

This section describes the mapping from IPP operation input parameters
to LPD control file lines (called `functions'). The mapper receives the
IPP operation input parameters via the IPP operation.  Each of the IPP
operation input parameters appear as sub-sections of section 3 and 4.2
in the IPP model document [1].

In the context of LPD control file lines, the text operands have a
maximum length of 31 or 99 while IPP input parameters have a maximum of
255 characters.  Therefore, there may be some data loss if the IPP
parameters exceed the maximum length of the LPD equivalent operands.

The mapper converts each supported IPP parameter to its corresponding
LPD function as defined by tables in the subsections that follow. These
subsections group functions according to whether they are:

  .  required with a job,
  .  optional with a job
  .  required with each document.

In the tables below, each IPP value is given a name, such as `h'. If an
LPD value uses the IPP value, then the LPD value column contains the IPP
name, such as `h' to denote this.  Otherwise, the LPD value column
specifies the literal value.

6.1 Required Job Functions

The mapper SHALL include the following LPD functions with each job, and
they SHALL have the specified value. They SHALL be the first functions
in the control file and they SHALL be in the order "H" and then "P".

IPP                           LPD function
name                  value   name  value         description

(in security layer)   h       H     gateway host  Originating Host
(in security layer)   u       P     u             User identification

A mapper SHALL sends its own host rather than the client's host, because
some LPD systems require that it be the same as the host from which the
remove-jobs command comes.  A mapper MAY send its own user name as user
identification rather than the client user. But in any case, the values
sent SHALL be compatible with the LPD remove-jobs operation.

Jacobs, Martin          Expires January 30, 1998

6.2 Optional Job Functions

The mapper MAY include the following LPD functions with each job. They
SHALL have the specified value if they are sent. These functions, if
present, SHALL follow the require job functions, and they SHALL precede
the required document functions.

IPP attribute                      LPD function
name           value               nam  value   description
                                   e

job-name       j                   J    j       Job name for banner
                                                page
job-sheets     `standard'          L    u       Print banner page
job-sheets     `none'                           omit `L' function
notification-  `job-completion'         user    Mail When Printed
                          user`@'                                          M       events         `mailto://'
notification-  host
method
Note: `L' has special meaning when it is omitted.  If `M' is omitted,
there is no notification. If `J' is omitted, some undefined behavior
occurs with respect to the banner page.

Note: the `user' for the `M' function comes from a substring of the
notification-method's value.

6.3 Required Document Functions

The mapper SHALL include one set of  the following LPD functions with
each document, and they SHALL have the specified values. For each
document, the order of the functions SHALL be `f', `U' and then `N',
where `f' is replicated once for each copy.

IPP attribute                  LPD function
name        value                   name  value  description

document-   `37'  (langAutomatic)   f     fff    Print formatted file
format      or `6'  (langPS).
copies      c                                    replicate `f' `c'
                                                 times
none                                U     fff    Unlink data file
document-   n                       N     n      Name of source file
name
Note: the value `fff' of the `f' and `U' functions is the name of the
data file as transferred, e.g. "dfA123woden".

Note: the mapper SHALL not send the `o' function

ISSUE: should we register DVI, troff or ditroff?
Jacobs, Martin          Expires January 30, 1998

If the mapper receives no "best-effort" or it has a value of false, then
the mapper SHALL reject the job if it specifies attributes or attribute
values that are not among those supported in the above tables.

Below is an example of the minimal control file for a job with three
copies of two files `foo' and `bar':

  H tiger
  P jones
  f dfA123woden
  f dfA123woden
  f dfA123woden
  U dfA123woden
  N foo
  f dfB123woden
  f dfB123woden
  f dfB123woden
  U dfB123woden
  N bar

7. References

[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., "Augmented BNF for Syntax Specifications: ABNF",
draft-ietf-drums-abnf-03.txt.

8. Author's Addresses

Robert Herriot (editor)              Norm Jacobs
Sun Microsystems Inc.                Sun Microsystems Inc.
901 San Antonio.Road., MPK-17        1430 Owl Ridge Rd.
Mountain View, CA 94043              Colorado Springs, CO 80919

Phone:  650-786-8995                 Phone:  719-532-9927
Fax: 650-786-7077                    Fax:   719-535-0956
Email:  robert.herriot@eng.sun.com   Email:
                                     Norm.Jacobs@Central.sun.com
Jacobs, Martin          Expires January 30, 1998

Thomas N. Hastings                   Jay Martin
Xerox Corporation                    Underscore, Inc.
701 S. Aviation Blvd., ESAE-231      41-C Sagamore Park Road
El Segundo, CA 90245                 Hudson, NH 03051-4915

Phone: 310-333-6413                  Phone:  603-889-7000
Fax:   310-333-5514                  Fax:  603-889-2699
EMail: hastings@cp10.es.xerox.com    Email:  jkm@underscore.com

9. Appendix A: ABNF Syntax for response of Send-queue-state (short)

The syntax in ABNF for the response to the LPD command `send-queue-state
(long)' is:

  status-response = empty-queue / nonempty-queue
  empty-queue = "no-entries" LF
  nonempty-queue = printer-status LF heading LF *(job LF)
  printer-status =  OK-status / error-status
  OK-status = printer-name SP "ready and printing" LF
  error-status = < implementation dependent status information >
  heading = "Rank" 3SP  Owner  6SP "Job" 13SP "Files"
                  23SP "Total Size" LF
                     ; the column headings and their values below begin
  at the columns
                     ; 1, 8, 19, 35 and 63
  job = rank *SP owner *SP job *SP files *SP total-size "bytes"
                    ; jobs are in order of oldest to newest
  rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
                    ; job that is printing is "active"
                    ; other values show position in the queue
  owner = <user name of person who submitted the job>
  job = 1*3DIGIT   ; job-number
  files = <file name> *( "," <file name>) ; truncated to 24 characters
  total-size = 1*DIGIT  ; combined size in bytes of all documents

10. Appendix B: ABNF Syntax for response of Send-queue-state (long)

The syntax in ABNF for the response to the LPD command `send-queue-state
(long)' is:

  status-response = empty-queue / nonempty-queue
  empty-queue = "no-entries" LF
  nonempty-queue = printer-status LF  *job
  printer-status =  OK-status / error-status
  OK-status = printer-name SP "ready and printing" LF
  error-status = < implementation dependent status information >
  job = LF line-1 LF line-2 LF
  line-1 = owner ":" SP rank 1*SP "[job" job SP host "]"
  line-2 =  file-name 1*SP document-size "bytes"
        ; jobs are indicated in
double quotes (") and input parameter order of oldest to newest
  rank = "active" / "1st" / "2nd" / "3rd" / integer "th"
Jacobs, Martin          Expires January 30, 1998
          ; job that is printing is "active"
          ; other values are indicated show position in the queue
  owner = <user name of person who submitted the job>
  job = 1*3DIGIT
  file-name = [ 1*DIGIT  "copies of" SP ] <file name>
                ; truncated to 24 characters
  document-size = 1*DIGIT  ;size of single
quotes (').  Values copy of the IPP "document-format" attribute that could be
registered, but are not currently, are indicated with "**".

           Mapping between document.

11. Appendix C: Unsupported LPD and IPP Protocols          June 27, 1997

Where there is a one-to-one mapping, both directions are specified.
Where functions

The follow LPD functions have no IPP has none, the equivalent. The LPD-to-IPP the attribute is ignored, mapper
ignores them and in the IPP-to-LPD the LPD feature is left unspecified. mapper does not send them.

     LPD command           Equivalent IPP input parameter(s)
     name   description

     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.

           Mapping between

The follow LPD and functions specify document-formats which have no 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
equivalent, unless someone registers them. The LPD-to-IPP mapper rejects
jobs that never
                         occurred.

l  Print file leaving    "document-format" = 'Automatic'
   control characters
                         In practice, this is often used as request such a rough equivalent to the `f'
                         directive.  Again it may mean one
                         of many document formats.

n format, and the IPP-to-LPD mapper does
not send them.

     LPD command
     name   description

     c      Plot CIF file
     d      Print ditroff output  "document-format" = 'ditroff' ** DVI file

o
     g      Plot file
     k      reserved for Kerberized clients and servers
     n      Print Postscript      "document-format" = 'ps' ditroff 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'
           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

ISSUE: we may move some of these 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
           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 the supported list.

Jacobs, Martin
    Underscore Inc.
    41-C Sagamore Park Rd.
    Hudson, NH 03051-4915

    Phone:  (603) 889-7000
    Fax:  (603) 889-2600
    Email:  jkm@underscore.com          Expires January 30, 1998