So we could have events like:
Slow down data transfer
Speed up data transfer
There is an even more important event for a device to send to a host:
Ready for another job
This event is useful for a number of configurations:
1. Such an event could anticipate the completion of the current job, so that
the devices could overlap jobs. Printers that completely interpret a
job or document before marking would want to indicate that they are ready
for the next job much sooner that printers that mark as they interpret.
Printers with a long output paper path may want to ask for the next job
while the output paper path is being emptied, so that the printer doesn't
slow down between jobs. A host that has a job would then be advised
that this device could accept it now. If the host did not have a job,
the host could still keep an indication that this device is a candidate
for a job when a new job is submitted to the host.
2. This event is especially useful for the IPP fan-out case of a server/host
that controls multiple devices represented by a single IPP Printer object.
3. This event is also useful for the simpler case where a device is
controlled by more than one host and the device wants to indicate that it
is ready for another job from any of the hosts (or from a particular one,
if the device is trying to be fair).
I just read the current Notification Requirements and it is focused on
events that end users needs, so the above event are ones that hosts
need, not end-users. But these events are NOT events that administrators
need. Usually in the IPP WG, we have been making the distinction between
end-users vs. system operators/adminstrators, not between end-users versus
servers/hosts that are submitting jobs to devices on behalf of end-users.
So are the above events in-scope for our IPP notification effort or
out of scope? I think the answer depends on whether the IPP WG is going
to tackle the host-to-device requirements for IPP.
Tom