Hi,
I agree with Mike, on both historical practice (don't surprise
clients in responses) and the previous Get-Jobs context
that is an obvious predicate for Cancel-Jobs. If the client
says "job-ids", then he should know what he's doing.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Fri, Oct 9, 2009 at 12:32 PM, Michael Sweet <msweet at apple.com> wrote:
> 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.
> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.