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

From: "Tom Hastings" <[email-masked]>
Date: Thu, 08 Oct 2009 14:42:45 -0700

I don't have an answer to this remaining issue for the new Cancel-Jobs
operation:

ISSUE: OK to say that after checking that all of the jobs are owned by the
requesting user (unless the requesting user is the operator), the Printer
MUST return the 'client-error-not-possible' for any jobs that are not in a
state that [RFC 2911] Section 3.3.3 Cancel-Job allows to be canceled and
MUST indicate which jobs cannot be canceled in the "job-ids" operation
attribute return in the response.

Or should we say that all of the jobs MUST be in a cancelable state, else
none of the jobs are canceled (but still the Printer MUST return the list
that are not cancelable in "job-ids" so that the client can tell the user
which jobs aren't cancelable.   I favor the former, since one of the jobs
that the user wants to cancel may have just completed, so the user would
have to resupply the request removing those jobs that have completed.  On
the other hand,  the good client could do an automatic Get-Jobs with the
original (new) "job-ids" operation attribute and ask for just the
"job-status" to help the user request the proper jobs - or the good client
could do a silent Get-Jobs before submitting the original Cancel-Jobs and
check for the user). 

I prefer that the Printer MUST cancel all jobs that are in the correct
state, but skip over and return the list that aren't in the proper state (as
long as all of them belong to the user or the user is the
Operator/Administrator).  But it is more complicated for the Printer and
requires the Printer to return the job-ids (1setOf integer(1:MAX)) in the
response for those jobs that are in the wrong state.  It is also somewhat
confusing for the client user, since it has an error, but some of the jobs
are canceled.

Thanks,

Tom

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Thu, 8 Oct 2009 14:51:08 -0700

I thought Ira and I *had* answered this, but...

On Oct 8, 2009, at 2:42 PM, Tom Hastings wrote:

> I don’t have an answer to this remaining issue for the new Cancel- 
> Jobs operation:
>
> ISSUE: OK to say that after checking that all of the jobs are owned  
> by the requesting user (unless the requesting user is the operator),  
> the Printer MUST return the ‘client-error-not-possible’ for any jobs  
> that are not in a state that [RFC 2911] Section 3.3.3 Cancel-Job  
> allows to be canceled and MUST indicate which jobs cannot be  
> canceled in the “job-ids” operation attribute return in the response.

So if any of the jobs in the job-ids set is owned by another user and  
the authenticated user is not an operator or admin, then the status is  
client-error-not-authorized.  If any of the jobs is not in the  
pending, pending-held, processing, or stopped states then the status  
is client-error-not-possible.

> ...
> I prefer that the Printer MUST cancel all jobs that are in the  
> correct state, but skip over and return the list that aren’t in the  
> proper state (as long as all of them belong to the user or the user  
> is the Operator/Administrator).  But it is more complicated for the  
> Printer and requires the Printer to return the job-ids (1setOf  
> integer(1:MAX)) in the response for those jobs that are in the wrong  
> state.  It is also somewhat confusing for the client user, since it  
> has an error, but some of the jobs are canceled.

Right, so I vote we don't allow partial cancels - we only succeed if  
all of the specified jobs can be canceled.

....

Oh, and there is one more error case - if Cancel-Jobs is sent with "my- 
jobs" set to true and there are no jobs that can be canceled for that  
user, we need to return client-error-not-found.

___________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Tom Hastings" <[email-masked]>
Date: Thu, 08 Oct 2009 16:43:55 -0700

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?

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).  

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?

Tom

  _____  

From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, October 08, 2009 14:51
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPP] ISSUE: on Cancel-Jobs: what if some jobs are in
cancelable state and some are not?

So if any of the jobs in the job-ids set is owned by another user and the
authenticated user is not an operator or admin, then the status is
client-error-not-authorized.  If any of the jobs is not in the pending,
pending-held, processing, or stopped states then the status is
client-error-not-possible.

...

Right, so I vote we don't allow partial cancels - we only succeed if all of
the specified jobs can be canceled.

....

Oh, and there is one more error case - if Cancel-Jobs is sent with "my-jobs"
set to true and there are no jobs that can be canceled for that user, we
need to return client-error-not-found.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 8 Oct 2009 16:57:22 -0700

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.

---

From: "Tom Hastings" <[email-masked]>
Date: Thu, 08 Oct 2009 18:50:25 -0700

I agree.  Sounds good.

Tom

  _____  

Sent: Thursday, October 08, 2009 16:57

Sounds reasonable.

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.

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.

---

From: "Tom Hastings" <[email-masked]>
Date: Fri, 09 Oct 2009 00:15:08 -0700

One small nit:

Michael wrote:

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?

  _____  

Sounds reasonable.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 9 Oct 2009 09:32:04 -0700

On Oct 9, 2009, at 12:15 AM, Tom Hastings wrote:
> 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.

>> 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.
>
>
> 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.
>
> 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.
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 9 Oct 2009 13:08:58 -0400

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: [email-masked]
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 <[email-masked]> wrote:
> 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?
>
> Second, because the client lacks the context information for a particular
> job-ids value. Consider the following situation:
> 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.
>
>
>
>
>
> ________________________________
>
> 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,
> If the user requests “my-jobs” = ‘true’, but there are no jobs that can be
> 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
> cancelable and as soon as it finds one that doesn’t belong to the requesting
> 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
> 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
> ISSUE: OK that the Printer doesn’t try to return which jobs are the ones
> a Get-Jobs (before or after a Cancel-Jobs request) with a “job-ids” supplied