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
- Re: what ever happened to npp? Brad Clements
- Re: what ever happened to npp? Steve Smith
- Re: what ever happened to npp? Bruce Crabill