Remote device access VS service provision
Bruce Crabill <BRUCE@umdd.umd.edu> Sat, 25 July 1992 17:08 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01267; 25 Jul 92 13:08 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01263; 25 Jul 92 13:08 EDT
Received: from inet-gw-2.pa.dec.com by NRI.Reston.VA.US id aa10354; 25 Jul 92 13:08 EDT
Received: by inet-gw-2.pa.dec.com; id AA11209; Sat, 25 Jul 92 10:08:14 -0700
Received: by nsl.pa.dec.com; id AA15125; Sat, 25 Jul 92 09:34:55 -0700
Received: by nsl.pa.dec.com; id AA15121; Sat, 25 Jul 92 09:34:54 -0700
Received: by inet-gw-1.pa.dec.com; id AA13726; Sat, 25 Jul 92 09:34:51 -0700
Message-Id: <9207251634.AA13726@inet-gw-1.pa.dec.com>
Received: by UMDD.UMD.EDU id 3370 ; 25 Jul 92 12:35:33 EDT
Received: by UMDD (Mailer R2.08 PTF008) id 3370; Sat, 25 Jul 92 12:35:31 EDT
Date: Sat, 25 Jul 1992 11:59:15 -0400
From: Bruce Crabill <BRUCE@umdd.umd.edu>
Subject: Remote device access VS service provision
In-Reply-To: Message received on Fri, 24 Jul 92 17:22:55 EDT
To: print-wg@pa.dec.com
I tend to view it to be more than just remote access to a printer. To me,
I'm more interested in standardizing what is basically a network spooling
system. The user submits print requests to a server using this protocol.
The server may or may not have direct communications with the printer
(via a serial line to a Laserwriter, PAP to a LPS/40, channel attachment
to a IBM 3800, etc). If not, then the server would use the same protocol
to forward the job to the server that does (or at least closer to the
server that does). The actual protocol to the device is a seperate issue
and maybe a single protocol is not sufficient. The Dec PAP protocol works
nicely for their LPS/40 class printers, but may not be suitable for other
printers. At the University of Maryland, we have a protocol called NPP
(and an offical TCP port by the same name) that we have been using to
address the submittal to the spool system portion. It is a SMTP like,
easy to implement protocol. Our current protocol spec needs a bit of
cleaning up, but I'll append it so you can get an idea of the protocol.
Bruce
-------------------------------------------------------------------------
Network Printing Protocol (NPP) Protocol Definition
NPP is a protocol designed to enable the queuing [spooling] of
files to network attached devices such as printers or other output
devices. 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 dependencies. 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. 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 (not counting the end-of-line carriage
return/linefeed pair) conforming to the Net-ASCII standard (e.g.
carriage returns are followed by 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 name (which can be no longer than
64 characters), followed by optional command arguments seperated by
one or more spaces, followed by the end-of-line carriage
return/linefeed pair. This end-of-line sequence will be indicated as
"<EOL>" in the examples included in this document. In some cases,
there is a variable amount of data appended to the command after the
end-of-line sequence. In this case, one of the command arguments will
contain the number of octets of data appended. An end-of-line sequence
does not follow data. With the exception of the host and userid
portions of the HELLO command, case is not significant in the command
name or the arguments associated with it.
Protocol Replies:
A reply consists of a three digit decimal response code and an
optional text message describing the reply followed by the end-of-line
sequence. When the option text portion is present, then it will be
seperated from the response code by at least one space. These replies
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.
[continuations?]
Request Success:
The first digit of the response code indicates the success of the
requested command. The following values are defined:
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 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.
Functional Group:
The second digit of the response 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
The command is not known or has an invalid argument.
x1x Information
Response to a GET command or other status type information.
x2x Connections
Information about the establishment and termination of the TCP
connection to the server.
x3x Authentication
Messages dealing with the authentication information provided
on the HELLO command. May also be received on the OPEN command
if the server has restricted queues.
x4x System
The response is related to server's spooling system (with the
exception of data transfer messages).
x5x File System
Information having to do with the transfer of data from the
client into the server's spooling 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. In implementing code to check the response
code, only the first digit needs to be checked, the second and third
digits are provided to help further classify a response, but the first
digit will indicate the success of a command.
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><EOL>
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. If
supplied, it must be seperated from the 220 response code by one or
more spaces.
Examples:
< 220 NPP Server ready [haven.umd.edu]<EOL>
< 220 You have reached the NPP server at UMDD.UMD.EDU.<EOL>
Command Descriptions:
Hello Initiate a session
HELLO <Version Id> <Host Id> <User Id> <Auth Type>
<Auth Data Length><EOL>[<Auth Data>]
Arguments:
Version Id Version of the protocol
Host Id Host who is enqueuing/has enqueued an object
User Id User who is enqueuing/has enqueued an object
Auth Type Type of authentication method
Auth Data Length Length of data used in authentication
Auth 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 identifier is an integer value indicating the version of
the protocol which the client is using. The only currently
acceptable value is "1". 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 of
authentication is to be used 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 authentication length is an integer field
indicating the length of the authentication data immediately
following the end-of-line sequence.
[we realize that the authentication mechanism needs some work, we
may need some specific authentication commands]
Examples:
> Hello 1 trout.ab.umd.edu fred 1 8<EOL>nK894n90
< 230 Welcome, user authenticated<EOL>
> Hello 1 umdd.umd.edu test 0 0<EOL>
< 231 Welcome, some restrictions apply<EOL>
> Hello 1 BRUCE-BIG-PC.UMD.EDU BRUCE 3 5<EOL>XYZZY
< 232 User valid, continue<EOL>
Open Open a queue
OPEN <Queue><EOL>
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><EOL>
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 ASCII printable characters
(from the subset of X'21' to X'7E'). 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 buffer size value which is returned indicates
the largest amount of data the server is willing to receive on a
write command. If the buffer size return value is 0, the client may
send any amount of data on a single WRITE command.
[we should explicitly define how to make the Qid unique]
Examples:
> Open lw<EOL>
< 210 fred@trout.ab.umd.edu.97a83b33 0<EOL>
> Open 3800<EOL>
< 219 BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397 4096<EOL>
Write Write data to a queue
WRITE <Count><EOL>[<Data>]
Arguments:
Count Number of bytes to write
<EOL> (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 sequence and should in all cases be
smaller than or equal to the buffer size 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 normal
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 command to
successfully complete the transfer. In the event of a connection
failure or the client issues a QUIT command without giving the
CLOSE 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<EOL>1234567890
< 350 Data Written<EOL>
Segue Seperate logical files
SEGUE<EOL>
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.
[this needs to be documented more completely...]
[and perhaps a better command name...]
Example:
> Segue<EOL>
< 341 Logical EOF marked<EOL>
Close Close a queue
CLOSE<EOL>
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 25x class message
indicating the data transfer completed successfully and the data
previously transferred via WRITE commands has been accepted by the
queuing system.
Example:
> Close<EOL>
< 250 Closed<EOL>
Quit Terminate a session
QUIT<EOL>
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 haven't been explicitly released
will be implicitly released.
Example:
> Quit<EOL>
< 220 So long, see you next time<EOL>
Remove Remove an item from a queue
REMOVE <Qid><EOL>
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 fred@trout.ab.umd.edu.97a83b33<EOL>
< 240 Object destroyed.<EOL>
Release Release an item to the queuing
system
RELEASE <Qid><EOL>
Arguments:
Qid Qid of object to release to queuing system
Description:
The RELEASE command will allow an object to be released to the
queuing system for processing. 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 fred@trout.ab.umd.edu.97a83b33<EOL>
< 240 Released<EOL>
Set Set an attribute for an item
SET <Qid> <Attribute> <Count><EOL>[<Value>]
Arguments:
Qid Qid of object to set attribute on
Attribute Attribute to set
Count Number of octets in attribute value
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 space characters. The count parameter
indicates the length in octets of the attribute value which
immediately follows the end-of-line sequence. 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:
[the following list may need additions or deletions]
BANNER <user identifier>
The user identification value to be output on the header
page. The default is to use "<User Id>@<Host Id>" using
the information supplied on 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 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 an 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. 0 is the highest priority (will be
printed first) and 127 is the lowest. 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 fred@trout.ab.umd.edu.97a83b33 delay 2<EOL>30
< 240 Attribute set<EOL>
> Set BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397 title 34<EOL>
> This is the title of the print out
< 241 Attribute set<EOL>
Get Get an attribute for an item
GET <Qid> <Attribute><EOL>
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><EOL><value>
The length return parameter indicates the length of the attribute
value which immediately follows the end-of-line sequence. The value
parameter consists of exactly length bytes of non-Net-ASCIIized
data which constitutes the value of the attribute requested.
Examples:
> Get fred@trout.ab.umd.edu.97a83b33 delay<EOL>
< 211 2<EOL>30
> Get BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397 TITLE<EOL>
< 212 34<EOL>This is the title of the print out
List
LIST <Queue><EOL>
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. Each Qid will be returned in a seperate 11x type
response with the end of list being marked with a 24x response. If
there are no Qids associated with the user, then just the 24x
response will be returned.
Examples:
> List lw<EOL>
< 110 fred@trout.ab.umd.edu.97a83b33<EOL>
< 241 List complete<EOL>
> List 3800<EOL>
< 110 BRUCE@BRUCE-BIG-PC.UMD.EDU.F8196620EDF10397<EOL>
< 110 BRUCE@BRUCE-BIG-PC.UMD.EDU.F81C9E319B7CFFE1<EOL>
< 241 List complete<EOL>
> List lps40<EOL>
< 242 Nothing found<EOL>
Examples:
The following is an example of a complete transaction.
[Open TCP connection to port 92]
< 220 NPP Server ready [haven.umd.edu]<EOL>
> HELLO 1 UMDD.UMD.EDU BRUCE 0 0<EOL>
< 230 Welcome, some restrictions apply<EOL>
> OPEN lps40<EOL>
< 210 BRUCE@UMDD.UMD.EDU.25d33b16.6e 65536<EOL>
> SET BRUCE@UMDD.UMD.EDU.25d33b16.6e TITLE 13<EOL>T1212 LISTING
< 242 Attribute set<EOL>
> WRITE 15561<EOL>(15561 bytes of data)
< 350 Data written<EOL>
> CLOSE<EOL>
< 250 Closed<EOL>
> RELEASE BRUCE@UMDD.UMD.EDU.25d33b16.6e<EOL>
< 240 QID Released<EOL>
> QUIT<EOL>
< 220 Adios<EOL>
[Close TCP connection]
- Remote device access VS service provision Steve Smith
- Remote device access VS service provision Bruce Crabill