One small nit:
Michael wrote:
That said, we should only include the job-ids attribute in the response if
it was supplied in the request, since otherwise we are only canceling jobs
that can be canceled at that moment.
However, if the unprivileged user supplies Cancel-Job with neither "job-ids"
and "my-jobs" (or "my-jobs" = 'false'), i.e., cancel all jobs that are in a
cancelable state, and there are jobs that are 'pending', 'pending-held',
'processing' that don't belong to the user, so that the Printer MUST reject
the Cancel-Jobs with client-error-not-authorized, why shouldn't the Printer
also return the list of "job-id" values of these jobs that didn't belong to
the user?
_____
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Thursday, October 08, 2009 16:57
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?
On Oct 8, 2009, at 4:43 PM, Tom Hastings wrote:
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?
Sounds reasonable.
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).
According to 3.1.7 of RFC 2911, any operation can include an unsupported
group in its response, regardless of the status code; there are handful of
status codes that require an unsupported group be present...
So, I think we are OK returning the job-ids that are causing the error in
the unsupported group of the response.
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?
I don't like that approach since it introduces a race condition - the
offending job might change state between Get-Jobs, Cancel-Jobs, and
Get-Jobs, so better for the printer to say what the problem is instead.
That said, we should only include the job-ids attribute in the response if
it was supplied in the request, since otherwise we are only canceling jobs
that can be canceled at that moment.
___________________________________________________
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/20091009/731791de/attachment-0001.html>