Subject: [IPP] Updated (new) Cancel-Jobs, enhanced Get-Jobs and Purge-Jobs uploaded - some issues needing resolution Thursday

From: "Tom Hastings" <[email-masked]>
Date: Thu, 08 Oct 2009 00:58:02 -0700

I've uploaded v8 of the new Cancel-Jobs, enhanced Get-Jobs and Purge-Jobs
uploaded at:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-Get-Jobs-Purge-Jobs-enhancement
s-v8-20091007.doc

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-Get-Jobs-Purge-Jobs-enhancement
s-v8-20091007.pdf

I'd like to get resolutions Thursday, as I finish the rest of Set 2 on
Thursday.

ISSUES for the new Cancel-Jobs operation are:

ISSUE: OK that the Printer MUST ignore "jobs-ids" if "my-jobs" = 'true' is
supplied, rather than reject the request and return the
'client-error-bad-request" status?

ISSUE: OK that the Printer MUST reject a request that does NOT specify a
list of jobs and does NOT specify "my-jobs" = 'true'?  What if the
requesting user is the operator?  Should this case cancel all jobs?

In other words, is it OK that the Cancel-Jobs operation does not allow the
Operator to cancel all jobs?

ISSUE: OK that the Printer cancels the ones owned, but not the ones not
owned?  Then the Printer can repeatedly perform Cancel-Job operations on
each job in the list, rather than checking the entire list before canceling
any

ISSUES for the Get-Jobs enhancement:

ISSUE: OK that the Printer MUST ignore "jobs-ids" if "my-jobs" = 'true' is
supplied, rather than reject the request and return the
'client-error-bad-request" status?

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: Ira McDonald <[email-masked]>
Date: Thu, 8 Oct 2009 13:31:58 -0400

Hi Tom,

My comments are inline below.

Except to note that the operation attribute
is correctly named "job-ids" (singular "job"
and plural "ids").  Please make sure to get
this right.

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 Thu, Oct 8, 2009 at 3:58 AM, Tom Hastings <[email-masked]> wrote:
> I’ve uploaded v8 of the new Cancel-Jobs, enhanced Get-Jobs and Purge-Jobs
> uploaded at:
>
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-Get-Jobs-Purge-Jobs-enhancements-v8-20091007.doc
>
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Jobs-Get-Jobs-Purge-Jobs-enhancements-v8-20091007.pdf
>
>
>
> I’d like to get resolutions Thursday, as I finish the rest of Set 2 on
> Thursday.
>
>
>
> ISSUE: OK that the Printer MUST ignore “jobs-ids” if “my-jobs” = ‘true’ is
> ‘client-error-bad-request” status?
>

<ira> Yes, OK - a legacy Printer wouldn't understand "job-ids" (in Get-Jobs)
and would ignore it, so the above is the right behavior.
</ira>

> list of jobs and does NOT specify “my-jobs” = ‘true’?  What if the

<ira> Cancel-Jobs is NEW, so we can make it solid.  Missing required
operation attributes must be a client error - it's NOT desirable that
Cancel-Jobs be able to cancel *all* jobs.
</ira>

> each job in the list, rather than checking the entire list before canceling

<ira> No, bad choice.  The Printer MUST immediately check that all members
of "job-ids" are owned by the end user (if not operator or admin requester),
so that it returns a privilege error and does NOT cancel ANY jobs.
</ira>

> ISSUE: OK that the Printer MUST ignore “jobs-ids” if “my-jobs” = ‘true’ is
> ‘client-error-bad-request” status?
>

<ira> Yes, OK - this is compatibile with legacy Printers that don't understand
(and must ignore) "job-ids".
</ira>

---

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

Ira,

Thanks for the replies.

So the Printer MUST check all of the jobs that have been requested, BEFORE
canceling any to see if any are NOT owned by the user.  If any are NOT owned
by the user, then NONE are canceled.  Sounds good and that check doesn't
have any race conditions.

ISSUE: OK to say that the Printer MUST return the list that are NOT owned in
the same "job-ids" (1setOf integer(1:MAX)) operation attribute in the
response?

There is a second kind of error that could occur for a subset of the
specified jobs that are owned by the user.  The jobs could be in the wrong
state.  RFC 2911 Cancel-Job has the following error table based on the state
of the specified job:

The IPP object MUST accept or reject the request based on the job's current
state and transition the job to the indicated new state as follows:

Current "job-state"

New "job-state"

IPP object's response status code and action:

'pending'

'canceled'

'successful-ok'

'pending-held'

'canceled'

'successful-ok'

'processing'

'canceled'

'successful-ok'

'processing'

'processing'

'successful-ok'  See Rule 1

'processing'

'processing'

'client-error-not-possible'  
See Rule 2

'processing-stopped'

'canceled'

'successful-ok'

'processing-stopped'

'processing-stopped'

'successful-ok'  See Rule 1

'processing-stopped'

'processing-stopped'

'client-error-not-possible'  
See Rule 2

'completed'

'completed'

'client-error-not-possible'

'canceled'

'canceled'

'client-error-not-possible'

'aborted'

'aborted'

'client-error-not-possible'

Rule 1:  If the implementation requires some measurable time to cancel the
job in the 'processing' or 'processing-stopped' job states, the IPP object
MUST add the 'processing-to-stop-point' value to the job's
"job-state-reasons" attribute and then transition the job to the 'canceled'
state when the processing ceases (see section 4.3.8).

Rule 2:  If the Job object already has the 'processing-to-stop-point' value
in its "job-state-reasons" attribute, then the Printer object MUST reject a
Cancel-Job operation.

Access Rights: The authenticated user (see section 8.3) performing this
operation must either be the job owner or an operator or administrator of
the Printer object (see Sections 1 and 8.5).  Otherwise, the IPP object MUST
reject the operation and return: 'client-error-forbidden',
'client-error-not-authenticated', or 'client-error-not-authorized' as
appropriate.

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

Thanks,

Tom

-----Original Message-----
From: Ira McDonald [mailto:[email-masked]] 
Sent: Thursday, October 08, 2009 10:32
To: [email-masked]; Ira McDonald
Cc: [email-masked]
Subject: Re: [IPP] Updated (new) Cancel-Jobs, enhanced Get-Jobs and
Purge-Jobs uploaded - some issues needing resolution Thursday

Hi Tom,

this right.

Cheers,

- Ira

winter:

  734-944-0094

summer:

  906-494-2434

 

</ira>

 

</ira>

 

</ira>

 

<ira> Yes, OK - this is compatibile with legacy Printers that don't
understand

</ira>

---

From: Michael Sweet <[email-masked]>
Date: Thu, 8 Oct 2009 11:36:18 -0700

We need to fully specify the Cancel-Jobs operation, as this is a new  
operation and not an extension of an existing operation (just copy the  
Cancel-Job description from RFC2911 and tweak...)

Also, "1.4 The job-ids (boolean) Printer Description attribute" should  
be "1.4 The job-ids-supported (boolean) ...".

Anyways, comments inline...

On Oct 8, 2009, at 12:58 AM, Tom Hastings wrote:

> I’ve uploaded v8 of the new Cancel-Jobs, enhanced Get-Jobs and Purge- 
> Jobs uploaded at:
> I’d like to get resolutions Thursday, as I finish the rest of Set 2  
> on Thursday.
>
> ISSUE: OK that the Printer MUST ignore “jobs-ids” if “my-jobs” =  
> ‘true’ is supplied, rather than reject the request and return the  

That sounds too ambiguous to me.  We should return client-error-bad- 
request if a client specifies both my-jobs and job-ids.

> ISSUE: OK that the Printer MUST reject a request that does NOT  
> specify a list of jobs and does NOT specify “my-jobs” = ‘true’?   
> What if the requesting user is the operator?  Should this case  
> cancel all jobs?
>
> In other words, is it OK that the Cancel-Jobs operation does not  
> allow the Operator to cancel all jobs?
>

No, Cancel-Jobs should cancel all jobs if my-jobs and job-ids are not  
specified, just as Purge-Jobs does.  The limitation is that only an  
operator/administrator can cancel other users' jobs, so an ordinary  
user sending a "Cancel-Jobs" operation without "my-jobs" or "job-ids"  
will only work if there are only jobs owned by that user.

> ISSUE: OK that the Printer cancels the ones owned, but not the ones  
> not owned?  Then the Printer can repeatedly perform Cancel-Job  
> operations on each job in the list, rather than checking the entire  
> list before canceling any
>

We want Cancel-Jobs to be atomic, so if any of the jobs (implicitly or  
explicitly via job-ids) are not owned by the user and the user is not  
an operator or administrator, the printer should return client-error- 
not-authorized, just like Cancel-Job does today.

> ISSUE: OK that the Printer MUST ignore “jobs-ids” if “my-jobs” =  
> ‘true’ is supplied, rather than reject the request and return the  

As for Cancel-Jobs, I think we need to return client-error-bad-request  
because of the ambiguity.

___________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Michael Sweet <[email-masked]>
Date: Thu, 8 Oct 2009 11:46:39 -0700

On Oct 8, 2009, at 10:31 AM, Ira McDonald wrote:
>> ...
>> ‘true’ is

I don't like doing this without some indication there is a problem.  
Returning client-error-conflicting-attributes is an alternate way to  
go without saying "bad request", or if we want to allow this (and  
ignore job-ids) then we should return successful-ok-ignored-or- 
substituted-attributes with job-ids in the unsupported group of the  
response.

Moreover, Cancel-Jobs is a NEW operation, so we should do it right.

>> specify a

Huh?  We *want* a way for an administrator to cancel all jobs without  
purging the job history.  Otherwise there is no way to atomically  
cancel all jobs on a printer...

>> not

Right, we agree here...

>> ‘true’ is

Same issue here as for Cancel-Jobs, but I am OK returning successful- 
ok-ignored-or-substituted-attributes since this is an existing  
operation.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 8 Oct 2009 11:48:41 -0700

On Oct 8, 2009, at 11:25 AM, Tom Hastings wrote:
> 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.
>
Yes, I agree with this approach, as it is consistent with Cancel-Job.

---

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

Michael wrote:

I'll do the same for the other new operation: Resubmit-Jobs as well.

Tom

  _____  

From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, October 08, 2009 11:36
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IPP] Updated (new) Cancel-Jobs, enhanced Get-Jobs and
Purge-Jobs uploaded - some issues needing resolution Thursday

Also, "1.4 The job-ids (boolean) Printer Description attribute" should be
"1.4 The job-ids-supported (boolean) ...".

That sounds too ambiguous to me.  We should return client-error-bad-request
if a client specifies both my-jobs and job-ids.

No, Cancel-Jobs should cancel all jobs if my-jobs and job-ids are not
specified, just as Purge-Jobs does.  The limitation is that only an
operator/administrator can cancel other users' jobs, so an ordinary user
sending a "Cancel-Jobs" operation without "my-jobs" or "job-ids" will only
work if there are only jobs owned by that user.

We want Cancel-Jobs to be atomic, so if any of the jobs (implicitly or
explicitly via job-ids) are not owned by the user and the user is not an
operator or administrator, the printer should return
client-error-not-authorized, just like Cancel-Job does today.