In adding the Restart-Job operation to the IPP/1.1 Model, I noticed an
inconsistency with Hold-Job.
Hold-Job has been specified to require rejection when the job is in the
'processing' or 'processing-stopped' states. The reason given is:
Note: In order to keep the Hold-Job operation simple, such a request is
rejected when the job is in the 'processing' or 'processing-stopped' states.
If an operation is needed to hold jobs while in these states, it will be
added as an additional operation, rather than overloading the Hold-Job
operation. Then it is clear to clients by querying the Printer object's
"operations-supported" (see Section 4.4.13) and the Job object's "job-state"
(see Section 4.3.7) attributes which operations are possible.
For Restart-Job, there is implementation OPTION 1 to accept the request when
the job is in the 'processing' or 'processing-stopped' states and restart
the job in the middle, thereby producing a partial job (which may or may not
be what the user intended). There is OPTION 2 to reject the request when
the job is in the 'processing' or 'processing-stopped' states.
I suggest that we drop OPTION 1 and add a note like the one above for
Restart-Job as well like:
Note: In order to keep the Restart-Job operation simple, such a request is
rejected when the job is in the 'processing' or 'processing-stopped' states.
If an operation is needed to hold or restart jobs while in these states, it
will be added as an additional operation, rather than overloading the
Restart-Job operation. Then it is clear to clients by querying the Printer
object's "operations-supported" (see Section 4.4.13) and the Job object's
"job-state" (see Section 4.3.7) attributes which operations are possible.
Ok?
Tom Hastings
(310) 333-6413