I think we have agreement. Since the Cancel-Jobs is now all or nothing, the
Printer MUST return an error code if any of the jobs could NOT be canceled,
even if all the rest could be.
So if any are not the user's, then return: client-error-not-authorized
(0x0403)
But if all are the user's, but some are not in a state to be canceled,
return: client-error-not-possible (0x0404)
If the user requests "my-jobs" = 'true', but there are no jobs that can be
canceled, return: client-error-not-found (0x0406)
If the user omits "job-ids" and omits "my-jobs" (or supplies the default
"my-jobs" = 'false'), return: client-error-not-authorized (0x0403). But
what if the only jobs that are cancelable are the user's? That could
successfully cancel all jobs as long as they all belonged to the user. An
implementation could to this easily, by simply checking each job that is
cancelable and as soon as it finds one that doesn't belong to the requesting
user, it stops checking and returns the client-error-not-authorized
(0x0403); if all jobs belong to the user, it cancels all of them and
returns: successful-ok (0x0000), OK?
If the operator requests all jobs be canceled by omitting both "job-ids" and
"my-jobs" (or supplied "my-jobs" = 'false'), and there are no jobs that can
be canceled, then return client-error-not-found (0x0406)
I don't see a good way to indicate which jobs are the offending jobs.
Returning the "job-ids" in the Unsupported attributes group with the values
removed that could have been canceled is about as close as I can get, but
that is for a successfully completed operation which returns the status
code: successful-ok-conflicting-attributes (0x0002).
ISSUE: OK that the Printer doesn't try to return which jobs are the ones
causing the rejection? Instead, OK just to indicate that the client can do
a Get-Jobs (before or after a Cancel-Jobs request) with a "job-ids" supplied
and get the status and ownership of each of the jobs to help the user?
Tom
_____
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Thursday, October 08, 2009 14:51
To: tom.hastings at alum.mit.edu
Cc: ipp at pwg.org
Subject: Re: [IPP] ISSUE: on Cancel-Jobs: what if some jobs are in
cancelable state and some are not?
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/17f9435d/attachment-0001.html>