I don't have an answer to this remaining issue for the new Cancel-Jobs
operation:
ISSUE: OK to say that after checking that all of the jobs are owned by the
requesting user (unless the requesting user is the operator), the Printer
MUST return the 'client-error-not-possible' for any jobs that are not in a
state that [RFC 2911] Section 3.3.3 Cancel-Job allows to be canceled and
MUST indicate which jobs cannot be canceled in the "job-ids" operation
attribute return in the response.
Or should we say that all of the jobs MUST be in a cancelable state, else
none of the jobs are canceled (but still the Printer MUST return the list
that are not cancelable in "job-ids" so that the client can tell the user
which jobs aren't cancelable. I favor the former, since one of the jobs
that the user wants to cancel may have just completed, so the user would
have to resupply the request removing those jobs that have completed. On
the other hand, the good client could do an automatic Get-Jobs with the
original (new) "job-ids" operation attribute and ask for just the
"job-status" to help the user request the proper jobs - or the good client
could do a silent Get-Jobs before submitting the original Cancel-Jobs and
check for the user).
I prefer that the Printer MUST cancel all jobs that are in the correct
state, but skip over and return the list that aren't in the proper state (as
long as all of them belong to the user or the user is the
Operator/Administrator). But it is more complicated for the Printer and
requires the Printer to return the job-ids (1setOf integer(1:MAX)) in the
response for those jobs that are in the wrong state. It is also somewhat
confusing for the client user, since it has an error, but some of the jobs
are canceled.
Thanks,
Tom
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20091008/0ec1cd5c/attachment-0001.html>