SOME REQUIREMENTS FOR NOTIFICATION.
(end-user perspective, NOT administrator)
1) User/client submits a job, and can not wait for confirmation. Might
be on travel or has more important business. Might have to go
off-line. (Client workstation from where the job was submitted might
be off). Perhaps the queue is long, or there are many large jobs
pending.
Here, the user simply wants to know, with high probability, if the job
has completed, but not in real time.
2) User wants confirmation as soon as print is complete. User will
wait for confirmation. Queue may be small and no large jobs pending.
Presumably job is not huge.
3) User wants confirmation as soon as print is complete, but printer
is being heavily used as determined by queue and pending job sizes.
User's job may or may not be large.
4) User does not care for confirmation.
6) Is a negative ACK required? For the cases when job can not be
printed although it is a perfectly valid print stream. (paper jam)
Is a notification necessary if the printer determines that there will
be a significant delay before printing?
7) Notification of print completion would be really useful to the
receiving party. Assuming that the party is not constantly watching
for output on the printer. Sorry if this is already in the model spec.
This is presumably an intranet thing.
SOME SITUATIONS:
1) Physical printer might run out of some resource such as paper or
ink or have a mechanical problem, after the job has been submitted.
Essentially this leads to UNPREDICTABLE delays in confirmation.
2) Server (assuming a non-embedded implementation) may have some
unrelated failure --- either with or without loss of received print
streams (after job submission).
ASSUMPTIONS:
1) Job has been validated and accepted (i.e., submitted) without
errors.