Re: what ever happened to npp?

Bruce Crabill <BRUCE@umdd.umd.edu> Thu, 03 December 1992 16:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05214; 3 Dec 92 11:57 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05210; 3 Dec 92 11:57 EST
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa16246; 3 Dec 92 11:58 EST
Received: by inet-gw-2.pa.dec.com; id AA22896; Thu, 3 Dec 92 08:57:58 -0800
Received: by nsl.pa.dec.com; id AA15314; Thu, 3 Dec 92 08:14:41 -0800
Received: by nsl.pa.dec.com; id AA15310; Thu, 3 Dec 92 08:14:40 -0800
Received: by inet-gw-1.pa.dec.com; id AA00609; Thu, 3 Dec 92 08:14:34 -0800
Message-Id: <9212031614.AA00609@inet-gw-1.pa.dec.com>
Received: by UMDD.UMD.EDU id 9400 ; 3 Dec 92 11:13:35 EST
Received: by UMDD (Mailer R2.08 PTF008) id 9400; Thu, 03 Dec 92 11:13:32 EST
Date: Thu, 03 Dec 1992 11:02:38 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bruce Crabill <BRUCE@umdd.umd.edu>
Subject: Re: what ever happened to npp?
In-Reply-To: Message received on Wed, 2 Dec 92 14:48:03 EST
To: print-wg@pa.dec.com

Actually, NPP is a protocol and it was presented to this group a year or two
ago.  The Network Printing Protocol (NPP, port 92) was developed at the
University of Maryland in order that we could have a common protocol for
network printing across a large number of platforms including IBM mainframes,
PCs, Macs, and Unix workstations.  LPR (as it actually works, not as
documented in RFC 1179), is ill-defined (at best) and not particually
efficent one some non-Unix hosts (like the IBM mainframes).  As such, we
designed a protocol that would be easy to implement on a variety of platforms
and follows the SMTP/FTP command structure.  We have implementations for
most of the popular platforms and have been actively using it in production
for some time now.  The protocol basically is used for client submission to
a spooling server, but it is also used to transfer files between servers.
The following is a description of the protocol (when I get some spare time,
I intend to get this into RFC format and to at least get it issued as an
informational RFC):


Network Printing Protocol (NPP) Protocol Definition


   NPP is a protocol designed to enable the queuing of files to network
attached devices such as printers (but not limited to). The protocol
follows the model used by SMTP and FTP. It is designed to be easy to
implement on a variety of systems with a minimum of system dependancies.
In the examples given below, lines that are prefixed with ">" are lines
that are sent from a client to a server and the lines prefixed with "<"
are responses from the server to the client. In the current
implementation, NPP uses port 92 for the server.

Protocol:

   The queuing protocol consists of a simple command/response client-
server model. The client issues commands to the server, and the server
supplies responses. The commands and responses consist of up to 256
ASCII characters (including the end of line pair) conforming to the Net-
ASCII standard (e.g. carriage returns are either followed by a NUL or a
linefeed). The data portion of commands such as Write and Set is
preceded by a count and the data may not necessarily consist of Net-
ASCII characters, thus care must be taken to insure the data portion of
a command is not converted into Net-ASCII form unless specified by the
mode attribute (see the Set command below).

Commands:

   A command consists of a command word (which can be no longer than 64
characters) followed by optional command arguments followed by the end-
of-line pair carriage return/linefeed. In some cases, the optional
command argument consists of a count of data indicating count octets of
data immediately follows the end-of-line pair. In all cases, with the
exception of the host and userid portions of the Hello command, case is
not significant, and all white space characters (with the single
exception of the end-of-line pair) are ignored.

Protocol Replies:

   A reply consists of a response code and an optional text message
describing the reply and are modeled after the FTP reply format. In some
cases, indicated by messages of the x1x class, the reply consists of
parsable data which must be understood by the client program.

Responses:

   1xx   Positive Preliminary Reply

         The command is in the process of completing successfully and the
         client should await further replies.

   2xx   Positive Completion Reply

         The command has completed successfully.

   3xx   Positive Intermediate Reply

         The command was successfully, but further commands are necessary
         for final completion of the command. For example, the Write
         command will return a 3xx message upon successful completion,
         thus indicating a Close or Flush command is necessary before the
         object can be guaranteed to be written to the queuing system.

   4xx   Transient Negative Completion Reply

         An error was encountered while processing the command, and the
         queuing system has therefore rejected the command. The command
         may be reissued with different parameters or after other
         commands and may work.

   5xx   Permanent Negative Completion Reply

         The queuing system detected an error from which it was unable to
         recover. This reply indicates a fatal error and the server will
         follow this reply by closing the connection.

Subsystems:

   The subsystem code indicates which part of the system is replying
with the response code. Special care should be taken with the class x1x
messages, as its data is intended to be parsable by the client program.

   x0x   Syntax
   x1x   Information
   x2x   Connections
   x3x   Authentication
   x4x   System
   x5x   File System

   The third digit is used to provide further granularity among error
messages of the same response and subsystem type, but has no
significance otherwise.

Initial Greeting:

   When a client initially connects to the server, the server will send
the client an initial greeting message. This message has the form:

   220 <greeting text>

   The 220 portion is required, but the greeting text format is at the
server's discretion. It is recommended that it identify the server type
and the name of the host that the server is running on.

   Examples:

      < 220 NPP Server ready [haven.umd.edu]
      < 220 You have reached the NPP server at UMDD.UMD.EDU.

Command Descriptions:

--------------------------------------------------
Hello    Initiate a session
--------------------------------------------------

   Arguments:

      Version Id           Version of the protocol
      Host identifier      Host who is enqueuing/has enqueued an object
      User identifier      User who is enqueuing/has enqueued an object
      Authentication type  Type of authentication method
      Password length      Length of password used in authentication
      (end-of-line)        (carriage return/linefeed)
      Password data        Data used in authentication

   Description:

      This command initiates a queuing session. A queuing session
   consists of all commands up to and including the Quit command. The
   version id is an integer value indicating the version of the protocol
   which the client is using. The host identifier is the fully qualified
   domain name of the host who is enqueuing or has enqueued an object,
   which may not necessarily be the name of the host which initiated the
   session. The user identifier is the userid of the user who is
   enqueuing or has enqueued an object. As with the host identifier, the
   user identifier is not necessarily the user who has initiated the
   queuing session. The host and userid fields of the Hello command are
   case sensitive, as they are used in validation which is server
   dependent. The authentication type indicates which method the
   password data is encrypted in and can be one of the following values:

      0  No authentication
      1  UNIX-DES
      2  Kerberos
      3  Plain text

      When no authentication is specified, the client is restricted in
   some commands. The password length is an integer field indicating the
   length of the password data immediately following the end-of-line
   pair.

   Examples:

      > Hello 20 camelot.umd.edu davidc 0 0
      < 220 Welcome, some restrictions apply.
      > Hello 20 umdd.umd.edu bruce 1 8^M^JnK894n90
      < 221 What do you want?
      > Hello 20 bruce-big-pc.umd.edu 3 9^M^Jxyzzy
      < 222 Howdy Doody!

--------------------------------------------------
Open     Open a queue
--------------------------------------------------

   Arguments:

      Queue Queue to enqueue object to

   Description:

      The Open command will open the specified queue for writing. This
   command will return an informational message which is to be parsed by
   the client program in the following format:

      21x <qid> <buffersize>

      The qid return parameter is the identifier to be used hereafter to
   reference the object which is in the process of being enqueued.
   Format of qids consists of up to 128 printable Net-ASCII characters
   not including any white space character. Care should be taken on the
   part of the server to insure global uniqueness, perhaps by including
   the server host and enqueuing userid along with a time stamp, as the
   qid must be globally unique throughout the entire queuing system. The
   buffersize value which is returned indicates the largest amount of
   data the server is willing to receive on a write command. If the
   buffersize return value is 0, the client may send any amount of data
   on a single Write command.

   Examples:

      > Open prl
      < 210 davidc@camelot.umd.edu.97a83b33 4096
      > Open lw
      < 219 bruce@useless.machine.umd.edu.1 0

--------------------------------------------------
Write    Write data to a queue
--------------------------------------------------

   Arguments:

      Count          Number of bytes to write
      (end-of-line)  (carriage return/linefeed)
      data           Count bytes of data

   Description:

      The Write command will write a specified amount of data to the
   queue which was opened on the previously specified open command. The
   count argument indicates the amount of data immediately following the
   end-of-line pair and should in all cases be smaller than or equal to
   the buffersize the server supplied on the response to the open
   command. The data transfer mode defaults to Net-ASCII but may be set
   to another value using the Set command (see below) prior to the
   issuance of the write command. The response from the write command is
   a 3xx message indicating further action need be taken prior to
   successful completion of the command. In this case, the queuing
   system is expecting a Close or Flush command to successfully complete
   the transfer. In the event of a connection failure or the client
   issues a Quit command, the queue will be implicitly closed and a
   Remove command will be issued on the qid generated by the previous
   Open command.

   Example:

      > Write 10^M^J1234567890
      < 340 Data Written

--------------------------------------------------
Segue    Seperate logical files
--------------------------------------------------

   Arguments:

      None

   Description:

      The Segue command is used to mark the logical end-of-file of the
   current file. This is useful where several files are being printed in
   a single request.

   Example:

      > Segue
      < 341 Data Written

--------------------------------------------------
Close    Close a queue
--------------------------------------------------

   Arguments:

      None

   Description:

      The Close command terminates a data transfer. After the close, the
   object enqueued will be held until either explicitly released via the
   Release command or implicitly released with the Quit command. The
   Close command will return a 2xx class message indicating the data
   transfer completed successfully and the data previously transferred
   via write commands will be guaranteed to be written to the queuing
   system upon release.

   Example:

      > Close
      < 250 Closed

--------------------------------------------------
Quit     Terminate a session
--------------------------------------------------

   Arguments:

      None

   Description:

      The Quit command will terminate a queuing session freeing up any
   resources associated with the session. If a qid is open when the Quit
   command is received, the qid will be implicitly closed and removed
   and the data will be lost. At the issuance of a Quit command, any
   closed qids which havent been explicitly released will be implicitly
   released.

   Example:

      > Goodbye
      < 220 Auf Wiedersehen

--------------------------------------------------
Remove   Remove an item from a queue
--------------------------------------------------

   Arguments:

      Qid        Qid of object to remove from the queuing system

   Description:

      The Remove command removes an object from the queuing system. An
   object may only be removed after it has been closed and before the
   object reaches the actual device(s) that implement the queue the
   object was enqueued to. If the client initiated the session with no
   authentication, Removes can only be applied to objects enqueued
   during the current session.

   Example:

      > Remove davidc@camelot.umd.edu.2385ba3
      < 250 Object destroyed.

--------------------------------------------------
Release  Release an item to the queuing system
--------------------------------------------------

   Arguments:

      Qid      Qid of object to release to queuing system

   Description:

      The Release command will allow an object to move from the queuing
   hold area to the actual device(s) which implement the queue the
   object was queued to. Note that releasing an object does not insure
   immediate printing, since many jobs may be enqueued before the object
   just released or the object may have a delay applied to it (see Set
   below). If the client initiated the session with no authentication, a
   release can only be applied to objects enqueued during the current
   session.

   Example:

      > Release davidc@camelot.umd.edu.2385ab73
      < 250 Released

--------------------------------------------------
Set      Set an attribute for an item
--------------------------------------------------

   Arguments:

      Qid            Qid of object to set attribute on
      Attribute      Attribute to set
      Count          Number of octets in attribute value
      (end-of-line)  (carriage return/linefeed)
      Value          Value of attribute to be applied to object

   Description:

      The Set command applies a specified value to a specified
   attribute. An attribute consists of a up to 64 Net-ASCII printable
   characters not including the white space characters. The count
   parameter indicates the length in octets of the attribute value which
   immediately follows the end-of-line pair. The attribute value may not
   necessarily be Net-ASCII characters, so care must be taken not to
   apply Net-ASCII transformations on the attribute value. The following
   attributes have been defined:

      BANNER   <user identifier>

               The user identification value to be output on the header
               page. The default is to use "<user>@<host>" as taken from
               the HELLO command.

      COPIES   <n>

               The number of copies of the given file that are to be
               output. The default is 1.

      FORMAT   TEXT or POSTSCRIPT

               The structure of the data in the given file. TEXT indicates
               normal text with any line formatting characters included in
               the text. POSTSCRIPT indicates that the file contains a
               PostScript(tm) program that should be executed by the output
               device. The default is TEXT.

      FORMFEED TRUE or FALSE

               If this is set to TRUE, then the device driver (if it
               supports such a feature) should insert a FF character
               between copies of a output file. The default is TRUE.

      FORMS    <form name>

               The name of the forms to be used to output the file. The
               default is "white".

      INDENT   TRUE or FALSE

               If this is set to TRUE, then the device driver (if it
               supports such a feature) may indent the output. The default
               is TRUE.

      MAIL     TRUE or FALSE

               If this is set to TRUE, then when the file is processed by
               the requested network device, the submitter is to be sent a
               mail message indicating this. The default is FALSE.

      MAILID   <user>@<host>.<domain>

               The mail address to be used for advisories (errors or if
               the MAIL attribute is set to TRUE). The default is to use
               the information supplied on the HELLO command.

      MODE     NETASCII, EBCDIC, or BINARY

               The representation of the data in the given file. The
               default is NETASCII.

      PRIORITY <n>

               A value in the range 0 to 127 that specifies the priority
               of the request. The default is 64.

      START    <n>

               The given file should be held until the indicated time.
               Time is given as seconds since midnight January 1, 1970.
               The default is to not hold the file.

      TITLE    <title>

               The title of the file to be output. This appears on the
               header page.

      XARG     <value>

               An extended argument that is given to the device driver.
               These extended arguments are device driver specific. More
               than one XARG attribute may be set.

   Examples:

      > Set davidc@camelot.umd.edu.347a372 delay 2^M^J30
      < 240 Attribute set
      > Set bruce@useless.machine.umd.edu.1 title 34^M^J
        This is the title of the print out
      < 241 Attribute set

--------------------------------------------------
Get      Get an attribute for an item
--------------------------------------------------

   Arguments:

      Qid         Qid of object to get attribute from
      Attribute   Attribute name to get value of

   Description:

      The Get command obtains the value of the specified attribute for
   the object denoted by the specified qid. The Get command will return
   a parsable response in the following format:

      21x <length>^M^J<value>

      The length return parameter indicates the length of the attribute
   value which immediately follows the end-of-line pair. The value
   parameter consists of exactly length bytes of non-Net-ASCIIized data
   which constitutes the value of the attribute requested.

--------------------------------------------------
List
--------------------------------------------------

   Arguments:

      Queue    Which queue to search for objects

   Description:

      The List command obtains a list of all qids associated with the
   userid specified on the Hello command which are currently in the
   queuing system.

Examples:

   The following is an example of a complete transaction.

   < 220 NPP Server ready [haven.umd.edu]
   > HELLO 1 UMDD.UMD.EDU BRUCE 0 0
   < 230 Welcome, some restrictions apply
   > OPEN lps40
   < 210 BRUCE@UMDD.UMD.EDU.25d33b16.6e 65536
   > SET BRUCE@UMDD.UMD.EDU.25d33b16.6e TITLE 13
   > T1212 LISTING
   < 242 Attribute set
   > WRITE 15561
   > (15561 bytes of data)
   < 350 Data written
   > CLOSE
   < 250 Closed
   > RELEASE BRUCE@UMDD.UMD.EDU.25d33b16.6e
   < 251 QID Released
   > QUIT
   < 220 Adios