I thought Ira and I *had* answered this, but...
On Oct 8, 2009, at 2:42 PM, Tom Hastings wrote:
> 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.
So if any of the jobs in the job-ids set is owned by another user and
the authenticated user is not an operator or admin, then the status is
client-error-not-authorized. If any of the jobs is not in the
pending, pending-held, processing, or stopped states then the status
is client-error-not-possible.
> ...
> 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.
Right, so I vote we don't allow partial cancels - we only succeed if
all of the specified jobs can be canceled.
....
Oh, and there is one more error case - if Cancel-Jobs is sent with "my-
jobs" set to true and there are no jobs that can be canceled for that
user, we need to return client-error-not-found.
___________________________________________________
Michael Sweet, Senior Printing System Engineer
--
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/8b8b9972/attachment-0001.html>