[IPP] ISSUE: on Cancel-Jobs: what if some jobs are in cancelable state and some are not?

[IPP] ISSUE: on Cancel-Jobs: what if some jobs are in cancelable state and some are not?

Michael Sweet msweet at apple.com
Fri Oct 9 16:32:04 UTC 2009


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>


More information about the ipp mailing list