On Oct 9, 2009, at 12:15 AM, Tom Hastings wrote:
> 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?
Two reasons: first, historically we have only returned unsupported
attributes for attributes that were provided in a request.
Second, because the client lacks the context information for a
particular job-ids value. Consider the following situation:
1. User foo submits job 123.
2. User bar does a Cancel-Jobs operation with no additional attributes
3. Cancel-Jobs returns client-error-not-authorized with job-ids=123
4. Job 123 completes and its history is aged out
5. User bar does a Get-Job-Attributes request to inspect job 123,
which fails with client-error-not-found.
There is also the case where local security policies do not allow user
bar to see (or get) user foo's job objects, so in that case the job-
ids values are not usable even when the job object is still around.
However, when the client provides a job-ids attribute, it must have
already gotten a list of valid job IDs (presumably with Get-Jobs) and
so it has the context for the jobs it is canceling.
>>> 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
>>>
___________________________________________________
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/f604597c/attachment-0001.html>