>3. Should Job State Reasons include any printer state reasons? Also, in
>1.4 we said that all Printer Status attributes were returned in the Job
>Submit response. We also stated that the semantics were based on the
>Printer status just befor the job "is submitted". However, we need to
>rethink this. If we put printer state reasons in the Job status attributes
>and we return Job Status attributes rather than Printer Status Attributes,
>then we solve the problem presented in the scenarios.
Bob and I suggest that the only printer state reason to add to the
job-state-reasons is printer-stopped.
The printer-stopped reason will be returned if and only if the Printer to
which the requester submitted the job is in the stopped state.
If the Printer is in the idle state or the processing state, there is
no need for a job-state-reason, since the job-state attribute will also
be returned (which is what the user is most interested in). That job-state
will be either pending or processing, depending on the situation.
Some systems may want to be optimistic and return the job as in the processing
state, if the Printer was idle and has the resources that the job needs
ready (without human intervention), even if the job is still transitioning
from pending to processing.
Comments?
Tom