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/20091008/8f540771/attachment-0001.html>