Table of Contents 
Previous Chapter The Andrew II Project:
Printing
J. Peter Neergaard
Computing Services
December 12, 1992
This document describes the functional requirements for the Andrew II Printing Project. The purpose of the project is to provide authenticated printing across the PC, Mac, and Unix environments at Carnegie Mellon. The solution must provide a native "look and feel" for all platforms, and be transparent to the user community.
The goals of the project also include enhancements to the current printing environment. These enhancements include improved tools for management, monitoring, and tracking. They would also provide improved resource management through quota and access controls. Dependencies on the local file system should be minimized.
The Requirements are divided into three sections: administrative, user and
system operator.
If you have any questions about the requirements, or if you are interested in providing or developing part or all of the Carnegie Mellon Printing System, please contact:
Mark Held
markh+@cmu.edu
(412) 268-5158
J. Peter Neergaard
jpn+@cmu.edu
(412) 268-3568
David Markley
markley+@cmu.edu
(412)268-7816
Aaron Wohl
n3liw+@cmu.edu
(412)268-5032
Fax to
(412) 268-4987
Features described in the Specific Requirements fall into three different categories --- Mandatory, Highly Desirable, and Desirable.
- Features that are mandatory must be included in the central computing
Printing System.
- Features that are highly desirable should be included in the central computing Printing System.
- Features that are desirable may be included in the central computing Printing System if they fall within our resource limitations.
It is mandatory that the printing system:
- accept print requests only from those clients which have been authenticated. In our environment, this would require the print client and spooler to exchange a kerberos ticket. This ticket would only be needed for those services configured to require authentication.
It is mandatory that the printing system:
- have a printcap server that would allow for central management of the printing environment at a university, departmental, or private level. This would remove the need of the printing system to have a printcap file distributed throughout the user base. The server would be responsible for providing any relevant information about any known printer and allowing administrators to update and change the printing environment in real time.
The printcap file would be automatically maintained and distributed as a backup to the printcap server. If the printcap server were unreachable, the printing systems would be able to get information through the traditional file lookup. It is also necessary to maintain the printcap file for utilities which rely on it for their alternate interfaces to the printing environment.
- allow the printcap server to selectively grant administrative access to subsets (departmental access) of the printcap database, in order to provide genuine central management and still retain flexibility for departmental administrators. This could be achieved with the use of ACLs within the printcap servers administrative interface.
- allow the printcap server to provide a list of printer features to clients upon request, in order to provide new functionality but still stay compliant with lpr/lpd. The client would need to know what features are available for individual printers. This information would also be available through the printcap file.
It is mandatory that the printing system:
- have the ability to restrict printer access from unauthorized use. Central or departmental administrators should have the flexibility to choose a centrally supplied method of restriction (by host, userID, ACL, quota, size) or provide their own restriction. This could be done by associating printers with a particular access server, through which permission could be granted or rejected. If specialized access for printers is needed, special access servers could be used for individual printers. If for any reason the access server would be unavailable, the default should be to grant access.
There is a need to track true printing usage. This information needs to be accessible not only by administrators, but also by the access servers. The accounting data would need to be updated regularly in order to allow the access server to correctly grant/reject requests based on quota restrictions.
It is mandatory that the printing system:
- provide for batch accounting
It is desirable that the printing system:
- provide for real time accounting.
It is highly desirable that the printing system:
- be able to route pending print jobs from one spooler machine, and forward them to another spooler machine. Store and forward is useful when reconfiguring the printing environment, such as in the case of a broken printer, without interfering with the end user. The rerouting could be accomplished with the printcap server. The forwarding of currently pending jobs needs to be addressed.
It is mandatory that the printing system:
- provide a comprehensive set of tools which will allow administrators to manage the printing environment. An access control mechanism needs to be associated with those tools. This could be accomplished with ACLs.
- provide a tool which allows administrators to manipulate queues and job entries. Manipulation of queue entries would include deletion, suspension, activation, forwarding, and prioritizing.
- provide a tool which allows administrators to manage user print quotas.
- provide a tool which allows administrators to manage queue configurations, creation, deletion, and routing in real time.
It is highly desirable that the printing system:
- provide a tool which allows administrators to manage host configuration. This would allow hosts to be quickly and easily setup to be print servers.
- be able to control when a job is printed according to an estimate of its size.
It is desirable that the printing system:
- be able to control when a job is printing according t its real size. The control should include the ability to configure a queue to 1) print smaller jobs first, and 2) print jobs beyond a configurable threshold only between certain hours.
It is highly desirable that the printing system:
- be able to print across authentication realms. A user logged into a Computer Science workstation should be able to print to a printer in Electrical and Computer Engineering. This could be done with kerberos cross realm authentication and printer aliases of the form printer@ece.cmu.edu.
It is mandatory that the printing system:
- have an absolute minimum of AFS dependencies. The system should continue to operate normally regardless of the state of AFS. This might require that some spooler machines have large local disks in order to hold large volumes of print requests.
It is mandatory that the printing system:
- allows uses to print jobs with the same native look and feel which they have become accustomed to. Utilities which print through standard printing environment interfaces should not be affected by any changes. A Mac user should be able to print to an AppleTalk printer via the chooser. A PC user should be able to print to a NetWare controlled printer. And, one printer should be able to service Macs, PCs, and UNIX machines.
It is mandatory that the printing system:
- accept and work with standard lpr/lpd interfaces. This is necessary to allow native UNIX environments to print to this system.
It is mandatory that the printing system:
- notify users that their printing jobs are complete. Methods could include mail, zephyr, netware, and possibly others.
It is mandatory that the printing system:
- notify users of problems or errors. The methods of notification could include mail, zephyr, netware, and possibly others. The type of errors would be subject to what the printer would be able to return. But most printer support general errors such as "out of paper" and "printer off line".
The user also needs to be notified when the software determines that a job should not be printed. This could occur when a user prints a job of an unknown format, in which case an appropriate filter would not be available. This would also catch the case of printing a binary file, which if not caught, could waste a lot of time and paper.
It is mandatory that the printing system:
- allow users to display the contents of the print queue. This information should include various information including the number of entries in the queue, the order of the queue, and the size of the entries.
It is mandatory that the printing system:
- give users control of their print jobs. This control should include deleting the entry, suspending/holding the entry, and changing the job characteristics.
It is highly desirable that the printing system:
- allow users to select from multiple paper types through software commands.
It is desirable that the printing system:
- send the print job's data across the network with encryption. The server would then need to decrypt the data before printing.
It is mandatory that the printing system:
- allow Operations to monitor print queues for a variety of information. The type of queue information operations might be interested in includes the number of job entries, the queue status, the printer status, and a list of the entries with their associated characteristics.
It is highly desirable that the printing system:
- allow multiple queues to be associated with one printer. This would allow for an easy implementation of queue characteristics such as paper types by queue.
It is highly desirable that the printing system:
- allow central printing locations to take advantage of load balancing. It would remove the burden of choosing which printer to print to from the user, while balancing the load over multiple printers.
It is desirable that the printing system:
- be able to give jobs priorities within a queue. This would allow operator/system managers/administrators to re-order the print queue.