I am emailing this issue ("Job-state for a forwarding server") to make sure
that
there is consensus for the editorial change that we are about to make in the
model document for IPP/1.1.
The issue is:
14) ISSUE: Job-state for a forwarding server?
Suggested clarified and addition: AGREED - 'completed' is ok, but also add
'queued-in-device' job state reason which MUST be supported. Bring out on
the DL for confirmation.
-----------------
The problem here is that when a forwarding-server (which may be a server
submitting to a printer via LPD) submits a job to a printer via a deficient
protocol, such as LPD, the forwarding-server gets no information about the
progress of the job. It only knows that the receiver accepted the job and
the job is completed from the forwarding-server's point of view. The only
solution is for a server to mark the job as "completed". The proposed
job-state-reasons "queued-in-device" tells a client that the "completed"
state is the forwarding-server's best guess. Without this job-state-reason,
a client cannot distinguish between the two meanings of "completed": a) the
job is really done b) the job was sent to a black hole.
Bob Herriot