To: geer, treese, jis, alix
Cc: tytso, marcus
Subject: Athena's print service requirements...
Date: Mon, 30 Nov 87 16:59:58 EST
From: Tony Della Fera <tony>


	As you all know, Athena is contemplating doing a public domain
reference implementation of the ISO/ECMA Print Service Standard.  In
reviewing this standard we are developing a "requirements" list to use
as a yardstick for Athena.

	I have prepared a first cut list of the key functions that
that Athena requires from its print service.  This list is complied
from the input that each of you have given me.  Here is the list, the
points are in NO PARTICULAR ORDER. Your comments are invited but I
must receive them before noon tomorrow.  At that time Dan and I will
ship this list to the Print Service Standard group at DEC.

					Tony...

==============================================================================

    1)	Authenticated job submission.  

		We require the ability to "plug in" Kerberos, the
		Athena Authentication Service.  This is necessary for
		many of the following points.

    2)	Post job accounting based upon number of pages printed and an
	authenticated UID.  

		Real printer use time is not necessarily important but
		may prove useful in the future.
	
    3)	Printer and/or print server access control based upon
	authenticated UID.

		We require the ability to turn services on and off and
		otherwise regulate their use on a per UID basis.

    4)	Static update, per job, quota control based upon authenticated
	UID.

		We require the ability to regulate the acceptability
		of jobs based upon a central quota database.  It is
		not required that that central database be dynamically
		modified by the print server (i.e., updated after each
		job printed etc.)

    5)	Logical device redirection.

		We require the ability to redirect files destined
		for one logical device to another.  This is necessary
		in cases where printers must be taken down for
		maintenance etc.

    6)	The print service must be able to queue to multiple physical
	printers of the same (or similar) type and multiple remote
	servers for load balancing.
	
		This is required for high volume output areas and
		areas where multiple sites share a central printing
		service.

    7)	Reliable and complete job error/status information return.

		This is a required for both the job submission phase
		and the document printing phase.  For exmaple:
		PostScript job output messages must find their way
		back to the submitting user.

    8)	Job completion and status notification.

		Notification should be user selectable: either via
		notification service or mail with a fall back to mail
		if the notification service does not succeed.  We
		require the ability to plug in Zephyr, the Athena
		Notification Service.

    9)	Ability to print on a user's local (private) printer.

		It should be simple for a user to install and use a
		local, 	privately maintained printer.  This should not
		require the intervention of any central facilities,
		services or staff.

    10)	No file queueing or stageing on the local workstation.

		It is very important that once a job has been
		successfully subimitted, it not require the
		preservation of ANY workstation state.

    11)	The system MUST be simple to operate both locally and remotely.

		It is vital that the facility operations staff not be
		required to be "highly computer literate".  We must
		make the assumption that operators do not know
		anything about the underlying system and will not be
		able to perform complicated service operations.

    12)	The system MUST be simple to manage and maintain from a
	central location.

		It is important that the central administration of the
		service be as simple and automatic as possible.  Any
		work that scales on a per-workstation basis will
		ultimately be unmanagable.  There should be nothing
		that required central administration to "visit" each
		server or printer (asside from standard maintenance,
		paper, etc).

    13)	There should also be incorporated a means of collecting and
	processing job statistics for operational/management purposes.

		For privacy reasons this data probably needs to be
		divorced from the user, but is nonetheless important
		for profiling the usage of the system, and thus tuning
		and managing it.  Any large installation (esp.
		Athena) will require this kind of functionality.


==============================================================================